DEV Community: Aftan Ahmad

AI Can Write Code. So What Makes You Valuable as a Developer?

Aftan Ahmad — Fri, 16 Oct 2026 08:40:00 +0000

AI is changing software development faster than most of us expected. Tasks that once required hours of coding can now be completed in minutes with the help of AI tools. Developers can generate entire functions, write tests, debug errors, and even build small applications by describing what they want.

This raises an important question:

If AI can write code, what makes a developer valuable?

The answer isn't to compete with AI at writing code. It's to become the kind of developer who knows what to build, why it matters, how to build it correctly, and how to ensure it works in the real world.

The future of software development isn't necessarily about writing more code. It's about solving better problems.

1. Stop Measuring Your Value by the Code You Write

For years, developers have measured their progress through the technologies they learn, the features they build, and the complexity of the code they can write.

AI is changing that equation.

Generating boilerplate, creating CRUD endpoints, writing basic queries, and producing standard components are becoming increasingly accessible. These skills still matter, but they are no longer enough to distinguish an experienced developer from someone who knows how to use an AI coding assistant.

Your value increasingly comes from the decisions behind the code.

Can you translate an unclear requirement into a working solution?
Can you identify the root cause of a production issue?
Can you recognize when an AI-generated solution is incorrect?
Can you design a system that remains reliable as it grows?
Can you understand the business problem you're solving?

AI can generate a solution. You need to determine whether it's the right solution.

Don't aim to be the developer who writes the most code. Aim to be the developer who consistently delivers the right outcomes.

2. Build Strong Fundamentals Instead of Chasing Every New Tool

Every few months, a new AI model, framework, coding assistant, or development workflow appears. It's tempting to believe that staying relevant means constantly learning the latest technology.

But tools change faster than fundamentals.

If you're a backend developer, invest in understanding:

Databases: indexing, query optimization, transactions, locking, and data modeling.
System design: scalability, caching, queues, service boundaries, and failure handling.
Networking: HTTP, DNS, TLS, proxies, and how distributed systems communicate.
Security: authentication, authorization, input validation, and common vulnerabilities.
Reliability: observability, retries, idempotency, monitoring, and disaster recovery.
Programming: data structures, algorithms, concurrency, and the behavior of your language and runtime.

These concepts become even more important when AI generates code quickly.

An AI assistant might suggest adding a cache to improve performance. An experienced developer asks whether the data can become stale, how invalidation will work, and what happens when the cache goes down.

The tool provides possibilities. Your fundamentals help you evaluate them.

You don't need to master everything at once. Choose the fundamentals most relevant to your work and deepen your understanding through practical problems.

3. Learn to Use AI Without Becoming Dependent on It

Avoiding AI entirely isn't a sustainable strategy. Neither is blindly accepting everything it produces.

The goal is to use AI as a force multiplier while retaining your ability to reason independently.

Use it to:

Explore unfamiliar codebases.
Generate repetitive code and initial implementations.
Understand unfamiliar libraries and APIs.
Draft unit tests and identify edge cases.
Review pull requests and investigate potential bugs.
Compare architectural approaches.
Automate repetitive development tasks.
Explain errors and suggest debugging strategies.

However, don't stop at accepting the output.

Read the generated code. Verify its assumptions. Run the tests. Inspect the database queries. Consider security implications. Measure performance when it matters.

One useful practice is to attempt a problem yourself before asking AI for a solution. Even if your first attempt is incomplete, you'll have a better foundation for evaluating its response.

Another is to ask AI to explain the trade-offs between two approaches instead of simply asking which one to use.

The objective is not to become dependent on AI for every answer. It's to become more capable because you know how to use it.

4. Become Better at Debugging and Understanding Complex Systems

Writing a function is one thing. Understanding why a production system fails under unexpected conditions is another.

Real software systems contain dependencies, historical decisions, imperfect data, resource constraints, race conditions, and failures that rarely appear in a simple example.

AI can help investigate these problems, but the investigation still requires careful reasoning and evidence.

For example, imagine an API becomes slow when a report processes millions of database records.

A superficial solution might be to ask AI to optimize the query.

A stronger approach is to investigate the entire execution path:

Measure the query's execution time and inspect its execution plan.
Determine whether indexes are being used effectively.
Examine memory consumption, connection pools, and concurrent workloads.
Check whether the application is loading unnecessary records into memory.
Evaluate pagination, streaming, background processing, or pre-aggregation.
Test the proposed changes against realistic data volumes.

This is where experienced developers can create significant value.

Learn to use logs, metrics, traces, profilers, query plans, and debugging tools. Develop the habit of forming hypotheses and validating them rather than changing code until something appears to work.

The ability to diagnose unfamiliar problems is a durable skill because the problems themselves keep changing.

5. Understand System Design and Engineering Trade-Offs

AI can suggest architectures, but good engineering requires decisions based on constraints.

Should you use a monolith or microservices? Should a task run synchronously or through a queue? Is caching worth the complexity? Does a feature need real-time updates? Should a report use live transactional data or a precomputed summary?

There isn't always one correct answer.

The best decision depends on factors such as traffic, data volume, latency requirements, operational complexity, budget, team size, and failure tolerance.

To improve your system-design skills, practice explaining not just what you would build, but why.

For every important decision, ask:

What problem does this solve?
What alternatives exist?
What are the trade-offs?
How will the system behave under failure?
How will we monitor and maintain it?
What might need to change as usage grows?

You don't need to design systems at the scale of the world's largest technology companies to benefit from system design.

Even a small SaaS product can teach you about tenant isolation, database design, rate limiting, background jobs, security, deployment, and observability.

Real constraints make these concepts meaningful.

6. Build Projects That Demonstrate Engineering Judgment

Tutorial projects can be useful for learning, but completing another basic to-do application rarely demonstrates much beyond familiarity with a framework.

Build projects that expose you to real engineering challenges.

Consider a few examples:

A multi-tenant SaaS backend

Implement tenant isolation, role-based permissions, audit logs, rate limiting, background jobs, and subscription limits.

A large-data processing service

Build a service that processes large CSV files, streams results, handles malformed records, and recovers from interrupted jobs.

A reporting system

Create an application that generates reports from substantial datasets, with query optimization, asynchronous processing, caching, and measurable performance targets.

A production-ready API

Add authentication, validation, structured logging, integration tests, Docker deployment, monitoring, and documented API contracts.

The important part isn't the number of features. It's the quality of the engineering decisions you can explain.

Document the challenges you encountered, the approaches you considered, the benchmarks you measured, and what you would improve next.

A well-executed project with clear technical reasoning can demonstrate more than several unfinished repositories.

7. Develop Business Understanding

Developers sometimes focus exclusively on technical implementation and overlook the reason a feature exists.

But companies don't hire developers merely to produce code. They hire them to help create business value.

Consider a request to export a large report.

The immediate task is to generate a downloadable file. The underlying problem might be that customers need timely access to millions of records without slowing down the application.

Understanding that distinction opens up better solutions: asynchronous exports, progress tracking, streaming, retention policies, or precomputed reports.

Business understanding helps you identify the actual problem before committing to an implementation.

Learn to ask:

Who uses this feature?
What problem are they experiencing?
How frequently does it occur?
What does success look like?
What are the costs of failure?
Can the problem be solved more simply?

This skill also helps you prioritize your learning. Instead of adopting technologies because they are popular, you can evaluate whether they solve problems worth solving.

8. Strengthen Communication and Collaboration

Technical ability matters, but communicating technical decisions is also part of engineering.

Developers need to explain risks, clarify requirements, document decisions, review other people's work, and coordinate changes across teams.

AI can help draft documentation and summarize technical concepts. However, you still need to understand your audience and communicate the implications clearly.

Practice explaining complex problems in simple language.

Instead of saying, "The query is inefficient because the execution plan contains an expensive sequential scan," explain what that means for the user, the system, and the cost of the proposed fix.

Learn to write useful pull request descriptions, architecture decision records, incident reports, and implementation plans.

A developer who can identify a problem, explain its impact, propose alternatives, and deliver a solution is valuable beyond their ability to write code.

9. Learn to Evaluate AI-Generated Code Critically

AI-generated code can look convincing while containing subtle problems.

It might introduce inefficient queries, insecure authorization checks, incorrect assumptions about library behavior, missing error handling, or tests that fail to cover important cases.

Make code verification a standard part of your workflow.

Before accepting an AI-generated implementation:

Check whether it satisfies the actual requirements.
Verify that authorization and tenant boundaries are enforced.
Review database operations and potential performance bottlenecks.
Test edge cases and failure scenarios.
Check dependencies and API behavior against reliable documentation.
Run relevant automated tests, linters, and security checks.
Review the final diff to identify unintended changes.

Passing tests is important, but it isn't proof that a system is correct. Tests can be incomplete, and an implementation can satisfy its tests while violating an unstated requirement.

Treat AI output as a proposal that requires engineering review, not as an authority.

10. Develop a Specialty While Maintaining Broad Knowledge

Trying to learn every technology is an exhausting strategy.

A more effective approach is to develop depth in a field while maintaining enough breadth to collaborate across the software development lifecycle.

Potential areas of specialization include:

Backend architecture and distributed systems.
Database performance and data engineering.
Cloud infrastructure and platform engineering.
Application security.
AI integration and AI-powered product development.
Reliability engineering and production operations.
Developer tooling and workflow automation.

You don't have to choose one specialty forever. Your interests and opportunities can evolve.

For example, a backend developer who understands databases, system design, cloud deployment, and AI-assisted development can take ownership of increasingly complex features.

The advantage isn't simply knowing more technologies. It's being able to solve a class of problems deeply and reliably.

11. Build a Habit of Continuous Learning

The pace of change makes continuous learning important, but learning doesn't have to mean spending every evening taking another course.

A sustainable approach combines reading, building, experimenting, and reflection.

Try a weekly routine:

Learn: Study one concept relevant to your current work.
Apply: Use it to solve a real problem or build a small experiment.
Review: Compare your implementation with alternative approaches.
Document: Write down what you learned and what surprised you.
Share: Explain the concept in a short article, technical note, or project write-up.

You can learn from official documentation, engineering blogs, technical books, open-source repositories, and postmortems from real incidents.

Prioritize depth over the number of topics covered. Understanding one concept well enough to apply it independently is often more valuable than superficially exploring ten new tools.

12. Take Ownership of Outcomes, Not Just Assigned Tasks

Perhaps the most important shift is moving from completing tickets to owning outcomes.

A task-focused developer might implement an endpoint, open a pull request, and move on.

An outcome-focused developer also considers whether the endpoint solves the intended problem, whether it is secure, how it performs under load, how it will be monitored, and whether other developers can maintain it.

Ownership doesn't mean doing everything alone or working unlimited hours. It means understanding your responsibilities, communicating risks, and following through on the quality of the work.

AI can accelerate implementation, but someone must still make the right decisions, verify the results, and remain accountable for the system.

That responsibility is a meaningful part of professional software engineering.

A Practical 90-Day Plan to Stay Relevant

You don't need to transform your career overnight. Start with a focused plan.

Days 1–30: Strengthen your foundations

Identify your three biggest technical weaknesses.
Choose one relevant area, such as database optimization or system design.
Use AI to assist with learning, but practice explaining concepts without it.
Study the architecture of a real application you already understand.
Improve your debugging and testing habits.

Days 31–60: Build something substantial

Choose a project that solves a real problem.
Define its requirements and architecture before implementation.
Use AI to accelerate development while reviewing every important change.
Add meaningful tests, logging, error handling, and documentation.
Measure at least one improvement, such as query latency or processing throughput.

Days 61–90: Demonstrate your capabilities

Deploy the project or create a reproducible demonstration.
Document the architecture and important trade-offs.
Write a technical article explaining a difficult problem you solved.
Review your code as if you were reviewing another developer's work.
Update your resume and portfolio with evidence of impact rather than a long list of technologies.

At the end of 90 days, you'll have more than a collection of courses. You'll have practical evidence of how you think, build, and solve problems.

Summarization of Everything we talked about through a visual so you can keep it safe!

Final Thoughts: The Developer Who Adapts Will Have the Advantage

AI will continue to change how software is built. Some tasks will become faster, certain skills will become less differentiating, and new opportunities will emerge.

No one can predict exactly how the software engineering job market will evolve. But betting your entire career on the idea that AI will never change development is unwise.

So is assuming that learning to write prompts is enough to guarantee a successful career.

The more durable strategy is to combine strong fundamentals, practical engineering experience, critical thinking, business understanding, and effective use of AI.

Don't abandon coding. Understand it more deeply.

Don't avoid AI. Learn to work with it intelligently.

Don't chase every new framework. Learn the concepts that help you evaluate frameworks.

And don't build your professional identity around tasks that can be automated. Build it around the problems you can solve.

AI may change how we write software, but the ability to understand problems, make sound decisions, and deliver reliable solutions will remain central to good engineering.

The goal isn't to prove that you can work without AI.

It's to become a developer who can accomplish more with AI while still knowing what they're doing—and why it matters.

5 JSON Problems Developers Face (And How to Solve Them Without Writing Extra Scripts)

Aftan Ahmad — Mon, 12 Oct 2026 04:49:07 +0000

If you work with APIs, configuration files, or backend services, you've probably spent more time dealing with JSON than you expected.

Maybe an API response contains hundreds of nested objects. Maybe two API responses look almost identical, but one field has unexpectedly changed. Or perhaps you need to validate a payload against a schema before integrating it into your application.

These tasks aren't particularly difficult individually, but they can interrupt your workflow.

Here are five common JSON problems and practical ways to solve them.

1. Comparing Two JSON Responses

Imagine you're debugging an API regression.

Yesterday, your endpoint returned:

{
  "user": {
    "name": "John",
    "role": "admin"
  }
}

Today, it returns:

{
  "user": {
    "name": "Jonathan",
    "role": "user"
  },
  "active": true
}

You could compare the documents manually, use a generic text diff, or write a script.

However, a text diff may report irrelevant differences caused by formatting or property order.

A structural JSON diff is more useful because it focuses on the data itself: added properties, removed properties, and changed values.

This is particularly helpful when debugging API changes, reviewing configuration updates, or comparing responses between staging and production.

For quick comparisons, a JSON-specific comparison tool can save you from writing a one-off script.

2. Extracting Values From Deeply Nested JSON

Consider an API response containing thousands of users, each with profiles, addresses, and account settings.

You only need the names of users whose age is greater than 18.

Manually navigating the structure becomes tedious. Writing JavaScript works, but sometimes you just want to inspect the data quickly.

This is where JSONPath comes in.

For example:

$.users[*].name

This expression selects the name property from every item in the users array.

A filter expression can narrow the results:

$.users[?(@.age > 18)]

The exact supported syntax depends on the JSONPath implementation, but the general idea is simple: query the data instead of manually traversing it.

JSONPath is especially useful when debugging API responses, inspecting test fixtures, and exploring unfamiliar payloads.

3. Generating a JSON Schema From Existing Data

Suppose you're integrating with an API and receive this payload:

{
  "id": 42,
  "name": "Sarah",
  "active": true,
  "roles": ["editor", "reviewer"]
}

You want to document the expected structure or validate future responses.

Writing a JSON Schema manually is straightforward for small objects, but it becomes tedious when the payload contains deeply nested objects and arrays.

A schema generator can infer a starting point from sample JSON.

For example, it can identify:

id as an integer
name as a string
active as a boolean
roles as an array of strings

One important caveat: a sample doesn't describe every possible valid payload.

If name can sometimes be null, or if some fields are optional, you may need to adjust the generated schema. Treat generated schemas as a starting point, not unquestionable truth.

4. Validating JSON Against a Schema

Generating a schema solves only half the problem. You may also need to check whether an incoming payload follows it.

Imagine your application expects:

{
  "name": "Sarah",
  "age": 28
}

But the API returns:

{
  "name": "Sarah",
  "age": "28"
}

The value looks reasonable, but age is a string rather than a number.

This difference can cause unexpected behavior in applications that rely on strict types.

JSON Schema validation helps identify these mismatches before they become harder-to-debug application errors.

It's useful for API integration, test data, configuration validation, and checking payloads before processing them.

For production systems, validation should also happen at the appropriate application boundary—not only in a browser-based utility.

5. Converting JSON to XML (And Back)

JSON is common in modern APIs, but XML still appears in legacy integrations, enterprise systems, configuration formats, and some external services.

When two systems expect different formats, you need a conversion step.

A converter can handle common structures automatically, but JSON and XML don't represent data in exactly the same way.

For example, XML has attributes, namespaces, and mixed text content. JSON doesn't have direct equivalents for all these concepts.

Arrays and repeated XML elements can also require explicit conversion rules.

For that reason, always inspect the output when converting complex documents. A successful conversion doesn't necessarily mean the original structure has been preserved perfectly.

One small improvement to your JSON workflow

For occasional tasks, a short script is often enough. For recurring tasks, dedicated tools can save time and reduce repetitive work.

I've been building a browser-based toolkit called MyJSONPal that brings these workflows together.

It includes JSON formatting and repair, conversion tools, TypeScript and Zod generation, and newer tools for structural comparison, JSONPath queries, schema generation, schema validation, and JSON/XML conversion.

One design decision I care about is privacy: the tools are designed to process data locally in the browser rather than uploading JSON to a server.

As always, verify a tool's behavior and privacy claims before pasting production data, API tokens, or other sensitive information into it.

Final thoughts

JSON itself is rarely the difficult part of backend development. The friction comes from repeatedly inspecting, comparing, transforming, and validating it.

A few practical techniques can make these tasks easier:

Use structural diffs instead of manually comparing large payloads.
Use JSONPath to extract values from nested documents.
Generate schemas to reduce repetitive setup work.
Validate payloads to catch type and structure mismatches early.
Check conversion rules when moving between JSON and XML.

These small improvements can save time during debugging and integration work—and let you spend more time building the actual application.

I Built a Tool to Turn Messy Bank Statement PDFs Into Spreadsheets

Aftan Ahmad — Sat, 03 Oct 2026 14:00:25 +0000

I Built a Browser-Based PDF Bank Statement Parser

I recently built and launched SheetParse, a browser-based tool that converts bank statement PDFs into spreadsheet-ready data.

https://sheetparse.com

The idea started with a simple problem: PDF is a great format for reading a bank statement, but it's a pretty terrible format when you actually want to work with the transaction data.

If you need to analyze, filter, reconcile, or move the transactions into Excel, you quickly end up dealing with manual copy-pasting or unreliable PDF converters.

So I decided to build my own solution.

The interesting part: bank statements aren't standardized

At first, I thought the problem would basically be:

PDF → Extract text → Parse transactions → Excel

It turned out to be much messier.

Different banks use completely different layouts.

Some have separate debit and credit columns. Others combine them. Transaction descriptions can span multiple lines. Headers and footers can appear between transactions. Some PDFs contain actual text, while others are essentially scanned images.

So the actual pipeline looks more like:

PDF
 ↓
Text extraction / OCR
 ↓
Statement detection
 ↓
Bank-specific parsing
 ↓
Transaction normalization
 ↓
Validation
 ↓
CSV / XLSX

I decided to process everything locally

One of the main decisions I made was to keep document processing in the browser whenever possible.

Bank statements contain sensitive financial information, so I didn't particularly like the idea of requiring users to upload their documents to a random server just to convert them.

With SheetParse, the document can be processed locally in the browser.

That also means I don't need a large backend infrastructure just to process someone's PDF.

Bank-specific parsers

Another thing I learned is that trying to create one universal parser isn't necessarily the best approach.

Instead, SheetParse has parsers designed around different statement formats, along with a generic parser for unsupported formats.

The goal is to normalize everything into a consistent structure such as:

Date
Description
Debit
Credit
Balance

Once the data is normalized, generating CSV or XLSX becomes much easier.

OCR is a different problem

Text-based PDFs and scanned PDFs are very different.

If a PDF contains actual text, extraction is relatively straightforward.

But if every page is essentially an image, there isn't any transaction text to extract.

That's where OCR becomes useful.

SheetParse uses OCR as a fallback for these types of documents.

The tradeoff is that OCR is slower and can introduce additional ambiguity, especially with things like numbers, dates and transaction descriptions.

Extraction isn't enough

One of the biggest things I learned while building this is that extracting rows isn't the same as extracting correct data.

For financial documents, an incorrect transaction can be worse than a missing transaction because it can silently affect someone's calculations.

So validation becomes important.

Things like:

duplicate transactions
broken dates
incorrect debit/credit values
transactions split across lines
repeated headers
page boundaries
running balances

all need to be considered.

The parser needs to understand the structure of the statement rather than simply grabbing everything that looks like a row.

Column Studio

I also wanted SheetParse to do more than simply extract the transactions and immediately export them.

That's why I built Column Studio in SheetParse.

After the data has been extracted, Column Studio lets you work with the resulting columns before exporting the final spreadsheet.

Instead of having to take the raw output into another tool just to make small changes, you can prepare the dataset within SheetParse itself.

The idea is to make the workflow closer to:

PDF
↓
Extract
↓
Clean / organize columns
↓
Review
↓
Export

This became particularly useful because different people want different spreadsheet structures.

Someone might only need:

Date | Description | Amount

while another workflow might need:

Date | Description | Debit | Credit | Balance

Rather than forcing one output format on everyone, Column Studio gives the user more control over the extracted dataset.

Why build it in the browser?

There were a few reasons.

Privacy

The document doesn't have to be uploaded to a backend just for parsing.

Infrastructure

There isn't a document-processing server running for every conversion.

Simplicity

The application can remain relatively lightweight.

Cost

Client-side processing reduces the infrastructure required to operate the service.

There are obviously tradeoffs too. Large PDFs and OCR can consume significant CPU and memory in the browser, so performance is something I'm continuing to work on.

What I learned

The biggest lesson wasn't really about PDF parsing.

It was that real-world documents are messy.

A parser can work perfectly against ten sample PDFs and then encounter a completely different layout in the eleventh.

That's why supporting more banks isn't simply a matter of adding another parser. Each format needs representative documents, edge cases and regression tests.

I'm now much more interested in the reliability and validation side of document processing than I was when I started the project.

SheetParse is live

The first public version is now available:

https://sheetparse.com

It currently supports multiple bank statement formats, a generic parser, and OCR fallback for scanned PDFs.

It's still an early project, but it's something I've wanted to build for a while, and it's finally out in the wild.

If you've worked with PDF parsing, OCR, financial data extraction, or document processing, I'd be interested to hear how you've approached similar problems.

What are some of the weirdest PDF formats you've had to deal with?

Why Your JSON Tools Freeze (And How We Fixed It with Web Workers)

Aftan Ahmad — Fri, 07 Aug 2026 14:01:20 +0000

If you’ve ever pasted a 15MB JSON file into a browser-based formatter, you’ve likely seen it: the screen freezes, typing lags, the browser throws an "Aw, Snap!" error, or the fan spins up like a jet engine.

The culprit isn't JavaScript being slow—it’s blocking the UI thread.

When you run JSON.parse(), complex regex replacements, or type generation on the main thread, you block rendering, user inputs, and animations.

In this article, we’ll look at how we built MyJSONPal—a client-side JSON and data studio—to process multi-megabyte payloads instantly without freezing the browser using React 19, CodeMirror 6, and Web Workers.

The Solution: Off-Main-Thread Processing

To keep the editor buttery smooth, we need to offload heavy computation to a background thread using a Web Worker.

[ Main Thread ] ----> postMessage(JSON) ----> [ Web Worker ]

CodeMirror / UI                               AST Auto-Fix / Conversions
      │                                                │
      └────────── Receive Output Back ────────────────┘

By decoupling computation from rendering:

The editor remains interactive at 60 FPS while background work happens.
Heavy processing never blocks typing or scrolling.
Large payloads are processed in parallel with the UI lifecycle.

Step-by-Step Architecture

1. Define a Unified Processing Contract

To keep workers predictable and type-safe, create a shared contract for all inputs and outputs.

// types.ts

export type TargetFormat =
  | 'json'
  | 'csv'
  | 'yaml'
  | 'typescript'
  | 'zod'
  | 'sql';

export interface TaskInput {
  action: 'format' | 'minify' | 'fix' | 'convert';
  code: string;
  targetFormat?: TargetFormat;
  indentation?: number;
}

export interface TaskResult {
  success: boolean;
  output: string;
  error?: {
    message: string;
    line?: number;
    column?: number;
  };
  metrics?: {
    originalBytes: number;
    outputBytes: number;
    timeMs: number;
  };
}

2. Create the Worker Task Processor

Inside worker.ts, listen for incoming messages, execute pure processing logic, and return the result.

// worker.ts

import { processJsonPayload } from './jsonProcessor';
import type { TaskInput } from './types';

self.onmessage = (event: MessageEvent<TaskInput>) => {
  const startTime = performance.now();

  try {
    const result = processJsonPayload(event.data);
    const endTime = performance.now();

    self.postMessage({
      ...result,
      metrics: {
        ...result.metrics,
        timeMs: Math.round(endTime - startTime),
      },
    });
  } catch (err: any) {
    self.postMessage({
      success: false,
      output: '',
      error: {
        message: err.message || 'Processing failed',
      },
    });
  }
};

3. Build a Worker Client with Fallback Support

Not every environment handles Web Workers the same way. For example:

Server-side rendering (SSR)
Embedded webviews
Restricted browser environments

Always provide a fallback path.

// workerClient.ts

import type { TaskInput, TaskResult } from './types';

let workerInstance: Worker | null = null;

function getWorker(): Worker | null {
  if (typeof window === 'undefined') return null;

  if (!workerInstance && window.Worker) {
    workerInstance = new Worker(
      new URL('./worker.ts', import.meta.url),
      {
        type: 'module',
      }
    );
  }

  return workerInstance;
}

export async function executeTask(
  input: TaskInput
): Promise<TaskResult> {
  const worker = getWorker();

  // Primary path: execute off-main-thread
  if (worker) {
    return new Promise((resolve) => {
      worker.onmessage = (e: MessageEvent<TaskResult>) =>
        resolve(e.data);

      worker.postMessage(input);
    });
  }

  // Fallback path: lazy-load on main thread
  const { processJsonPayload } = await import('./jsonProcessor');

  return processJsonPayload(input);
}

4. Connect It to React & CodeMirror 6

Now wire asynchronous processing into your editor using debouncing to avoid flooding worker threads on every keystroke.

// EditorWorkspace.tsx

import React, {
  useState,
  useEffect,
  useCallback,
} from 'react';

import { executeTask } from './workerClient';

export const EditorWorkspace = () => {
  const [inputCode, setInputCode] = useState('');
  const [outputCode, setOutputCode] = useState('');
  const [isProcessing, setIsProcessing] = useState(false);

  const handleTransform = useCallback(async (code: string) => {
    if (!code.trim()) return;

    setIsProcessing(true);

    const result = await executeTask({
      action: 'convert',
      code,
      targetFormat: 'typescript',
    });

    if (result.success) {
      setOutputCode(result.output);
    } else {
      console.error(result.error?.message);
    }

    setIsProcessing(false);
  }, []);

  useEffect(() => {
    const timer = setTimeout(() => {
      handleTransform(inputCode);
    }, 150);

    return () => clearTimeout(timer);
  }, [inputCode, handleTransform]);

  return (
    <div className="grid grid-cols-2 gap-4">
      <textarea
        value={inputCode}
        onChange={(e) => setInputCode(e.target.value)}
        placeholder="Paste JSON here..."
      />

      <div className="relative">
        {isProcessing && (
          <div className="absolute top-2 right-2 text-xs">
            Processing...
          </div>
        )}

        <pre>{outputCode}</pre>
      </div>
    </div>
  );
};

Bonus: The "Magic" Auto-Repair Pattern

Moving processing into a worker unlocks CPU budget for automatic JSON repair without affecting UI responsiveness.

For example, you can handle:

Trailing commas
Single quotes
JavaScript comments
Python literals (True, False, None)
Unquoted object keys

// jsonFixer.ts

export function repairJson(dirtyJson: string): string {
  return dirtyJson
    // Remove UTF-8 BOM
    .replace(/^\uFEFF/, '')

    // Replace Python/JS literals
    .replace(/:\s*True\b/g, ': true')
    .replace(/:\s*False\b/g, ': false')
    .replace(/:\s*None\b/g, ': null')

    // Remove JS comments
    .replace(
      /\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm,
      '$1'
    )

    // Fix unquoted keys
    .replace(
      /([{,]\s*)([a-zA-Z0-9_]+?)\s*:/g,
      '$1"$2":'
    )

    // Convert single quotes
    .replace(
      /'([^'\\]*(\\.[^'\\]*)*)'/g,
      '"$1"'
    )

    // Remove trailing commas
    .replace(/,\s*([}\]])/g, '$1');
}

Because this logic runs inside a worker, even large malformed files can be repaired without causing frame drops or blocking the UI.

Results & Takeaways

By moving payload processing, AST repair, and type generation into a Web Worker architecture, we achieved three major improvements:

🚀 Zero Thread Blocking

Typing, scrolling, and editor interactions remain smooth at 60 FPS, regardless of JSON file size.

🔒 True Data Privacy

All processing happens entirely in the browser. No payloads are uploaded, stored, or transmitted to remote servers.

⚡ Instant Feedback

Even large datasets can be transformed in under 20ms without freezing the browser.

Try It Yourself

You can try this exact architecture in production with MyJSONPal — a free, privacy-first JSON studio built with:

Astro
React 19
CodeMirror 6
Tailwind CSS v4
Web Workers

Final Thoughts

Web Workers aren't just an optimization anymore—they're a requirement for modern browser-based developer tools handling large datasets.

If your users are working with multi-megabyte files, schema generation, AST transforms, or code conversion, moving heavy processing off the main thread is one of the highest-impact performance improvements you can make.

How are you handling heavy processing in your client-side applications? Let me know in the comments 👇

I got tired of online JSON tools crashing on syntax errors and conversions, so I built a local-first repair engine

Aftan Ahmad — Sat, 01 Aug 2026 15:52:52 +0000

Every developer uses online JSON formatters daily to debug API responses, inspect log files, or check database dumps.

But standard JSON formatters come with two recurring papercuts:

Parser Fragility: Standard JSON.parse is unforgiving. A single trailing comma, missing quote, or Python-style True/False boolean completely crashes the formatter, forcing you to fix it manually character by character.
Data Privacy Risks: Pasting production payloads, JWTs, or environment variables onto unencrypted, third-party server-side formatters is a security risk waiting to happen.

To solve both issues for my own workflow, I built MyJSONPal—a 100% client-side JSON studio designed for speed, privacy, and auto-repair.

⚡ 1. Magic AST Auto-Repair

Instead of failing on malformed JSON, MyJSONPal uses a client-side parsing engine that automatically cleans common syntax issues before formatting:

Trailing Commas: Strips trailing commas from arrays and objects.
Quote Normalization: Converts single-quoted strings and unquoted object keys into valid double-quoted JSON.
Language Equivalents: Automatically normalizes Python booleans (True/False) and None values into standard JSON syntax (true/false/null).

🔒 2. 100% In-Browser Privacy

Security shouldn't be an afterthought when inspecting API responses.

MyJSONPal runs entirely in your browser. There are zero server network calls, zero tracking logs, and zero remote data stores. Your production payloads and tokens never leave your local machine.

🛡️ 3. One-Click Type & Schema Generation

When integrating APIs, formatting the JSON is only step one. You usually need type definitions next.

MyJSONPal instantly infers:

Zod Schemas: Generates ready-to-use z.infer schemas for immediate runtime validation.
TypeScript Interfaces: Converts raw payloads into clean TS types.
Data Exports: Converts JSON directly to CSV (RFC 4180 compliant) and YAML.

Additional Core Features

Beyond the AST Auto-Repair, Client-Side Privacy, and Type Generation already covered, here are the additional core features built into MyJSONPal that make it a complete JSON workbench.

1. Advanced Structural Transformations

Recursive Key Sorting
- Instantly sorts all keys in nested objects alphabetically (A–Z or Z–A) to standardize payloads before committing or comparing.
Smart Minification & Formatting
- Switch between minifying payloads into a single line for API calls or formatting them with customizable tab or space indentation.
Key Extraction & Dot-Notation
- Flatten complex nested structures and extract all keys along with their precise dot-notation paths (e.g., user.profile.settings.theme).

2. Deep Data Conversion Pipeline

Bi-directional Conversions
- Convert JSON seamlessly into YAML, CSV (RFC 4180), or XML, and vice versa.
Base64 & Stringify Tools
- Decode Base64 payloads (such as JWTs) directly into structured JSON, or escape raw JSON into stringified literals ready for use in code variables.

3. Visual Exploration & Search

Interactive Collapsible Tree View
- Navigate massive multi-megabyte payloads with expandable and collapsible nodes, making it easy to inspect deeply nested responses.
Live Search & Path Finder
- Search for specific keys, values, or array indices across large datasets without slowing down the editor.

4. Performance & UX Foundations

Web Worker Architecture
- Heavy processing runs inside isolated background threads, keeping the UI responsive even when working with large database exports.
Shared Workspace State
- Paste your JSON once and switch between validators, converters, and generators without losing your input or re-uploading files.
VsCode Styled Editor
- Enjoy syntax highlighting, error-line navigation, dark/light theme support, and offline-first functionality.

🚀 Try It Out

It's completely free to use with no account required:

👉 myjsonpal.com

I’d love to hear your feedback! What JSON edge cases or converter options would make your daily debugging workflow easier? Let me know in the comments below!