DEV Community: Aditya Negandhi

Implementing a JSON Parser

Aditya Negandhi — Fri, 09 Oct 2026 18:25:51 +0000

Ever wondered how applications understand and process data from APIs? The magic often lies in a data format called JSON. This human-readable format is widely used to transmit data over the internet. But how do computers interpret this data? That's where JSON parsers come in.

In this devlog, we'll implement a JSON parser using Deno and Typescript which can parse local JSON files as well as JSON responses from an API. The thing I want you to take away: a parser is two small programs. A tokenizer turns characters into tokens, and a recursive function per grammar rule turns tokens into a tree. JSON's grammar is small enough to see the whole idea in one sitting.

What is JSON and why is it everywhere? 🤔

JSON, or JavaScript Object Notation, is a lightweight, text-based data-interchange format. It's the de facto standard for data transmission over the internet, especially in APIs. Its simplicity and readability make it a favorite among developers.

Language-Independent: It's not tied to any specific programming language.
Data Structures: It allows for complex data structures, making it versatile.
Efficient Parsing: It's relatively easy to parse, leading to fast processing.

//  This is what a valid JSON looks like:
{
  "name": "Alice",
  "age": 25,
  "isDeveloper": true
}

Its use cases range from transmitting API responses to saving application settings. But how does software make sense of JSON? That's where parsers come into play.

What is a Parser? 🧐

At its core, a parser is a program that converts text into a structured format and rejects anything that does not follow the grammar. For JSON, the parser's job is to transform raw strings into usable objects or data structures. The process typically involves two steps:

Tokenizing (Lexical Analysis): Breaking the input into meaningful chunks called tokens (e.g. {, "name", :, "Alice").
Parsing (Constructing AST's): Arranging these tokens into a hierarchical structure, known as an Abstract Syntax Tree (AST), that represents the JSON data.

Example:

// Here's a JSON snippet:
{ "id": 1, "isActive": true }

After tokenizing, it becomes:

[
  { type: "BraceOpen", value: "{" },
  { type: "String", value: "id" },
  { type: "Colon", value: ":" },
  { type: "Number", value: "1" },
  { type: "Comma", value: "," },
  { type: "String", value: "isActive" },
  { type: "Colon", value: ":" },
  { type: "True", value: "true" },
  { type: "BraceClose", value: "}" },
];

After parsing, the Abstract Syntax Tree (AST) looks like this:

{
  type: "Object",
  value: {
    id: { type: "Number", value: 1 },
    isActive: { type: "Boolean", value: true }
  }
}

Here's a visual flow of parsing a valid JSON :

Here's a visual flow of parsing a invalid JSON :

Implementing a JSON Parser using Deno and Typescript 🛠️

Using Deno because, it comes with out-of-the-box support for Typescript and lots of other cool tools like test-runners, coverage-checker etc.

# The project structure is as follows:

/json-parser
      ├── main.ts          # Entry point for the application
      ├── parser.ts        # Contains the parser logic
      ├── tokenizer.ts      # Contains the tokenizer logic
      ├── types.ts         # Type definitions for tokens and AST nodes
      └── utils.ts         # Utility functions for type checking
      │
      ├── main_test.ts     # Contains tests for the parser and tokenizer
      └── test-data.json   # Sample JSON data for testing
      │
      ├── deno.json                # Deno configuration file
      ├── .vscode/settings.json     # VSCode settings for Deno
      └── deno.lock                # Deno lock file for dependencies

Implementing Tokenizer (Lexical Analysis)

Tokenizing is always the first step when writing your own interpreter or compiler. Even your favorite prettifiers tokenize the entire file before prettifying it. Tokenizing involves breaking the code or input into smaller, understandable parts. This is essential because it allows the parser to determine where to start and stop during the parsing process.

Tokenizing helps us understand the structure of the code or input being processed. By breaking it down into tokens, such as keywords, symbols, and literals, we gain insight into the underlying components. Additionally, tokenizing plays a crucial role in error handling. By identifying and categorizing tokens, we can detect and handle syntax errors more effectively.

It is important to only use the grammar provided in ECMA-404 for tokenizing JSON (the diagrams on json.org are the same grammar drawn out). This ensures that the tokenizer can correctly identify and categorize JSON tokens.

Here's an example of how tokenizer.ts file looks:

export const tokenizer = (input: string): Token[] => {
  let current = 0;
  const tokens: Token[] = [];

  while (current < input.length) {
    let char = input[current];

    if (char === "{") {
      tokens.push({ type: "BraceOpen", value: char });
      current++;
      continue;
    }
    // handlers for other token types (e.g., strings, numbers, etc.)
  }
};

Implementing Parser (Constructing AST's)

The parser is where we make sense out of our tokens. Now we have to build our Abstract Syntax Tree (AST). The AST represents the structure and meaning of the code in a hierarchical tree-like structure. It captures the relationships between different elements of the code, such as statements, expressions, and declarations.

Here's an example of how parser.ts file looks:

function parseValue(): ASTNode {
  const token = tokens[current];
  switch (token.type) {
    case "String":
      return { type: "String", value: token.value };
    case "Number":
      return { type: "Number", value: Number(token.value) };
    case "True":
      return { type: "Boolean", value: true };
    case "False":
      return { type: "Boolean", value: false };
    case "Null":
      return { type: "Null" };
    case "BraceOpen":
      return parseObject(); // recursive fn
    case "BracketOpen":
      return parseArray(); // recursive fn
    default:
      throw new Error(`Unexpected token type: ${token.type}`);
  }
}

Testing our JSON Parser

In order to ensure that our parser is working correctly and supporting all the ECMA-404 Standards, we need to write tests. We also need to check for edge cases like \n, \t, \r, \f, and \b characters for Strings, - for negative numbers and so on.

Here's an example of how main_test.ts file looks:

Deno.test("parser should correctly parse an array with mixed types", () => {
  const jsonString = `[-1, "string\n\t\r\f\b", true, null, {}]`;
  const tokens = tokenizer(jsonString);
  const ast: ASTNode = parser(tokens);

  assertEquals(ast, {
    type: "Array",
    value: [
      { type: "Number", value: -1 },
      { type: "String", value: "string\n\t\r\f\b" },
      { type: "Boolean", value: true },
      { type: "Null" },
      { type: "Object", value: {} },
    ],
  });
});

Deno.test("parser should throw an error for invalid JSON", () => {
  const jsonString = `{
    "key": "value",
    "invalid": 
  }`;

  const tokens = tokenizer(jsonString);

  try {
    parser(tokens);
    throw new Error("Expected an error to be thrown for invalid JSON");
  } catch (e) {
    assertEquals((e as Error).message, "Unexpected token type: BraceClose");
  }
});

// More tests...

Learnings from this project 📚

We learned about the crucial concept of tokenizing, breaking down the code into smaller, understandable parts. This sets the foundation for the parser to work its magic.

Our tokenizer expertly handles JSON strings and produces an array of tokens that capture the essence of the data structure.

Moving on to the parser, we built an Abstract Syntax Tree (AST) that neatly organizes the key-value pairs and nested structures of the JSON data.

So, with our tokenizer and parser working hand in hand, we can confidently say that we've successfully crafted our very own JSON parser!

Where this stops applying

Passing my tests is not the same as being correct. The tests above cover the cases I thought of. JSONTestSuite has hundreds of files that real parsers disagree on, and it is the honest benchmark for any parser that claims to follow the standard.

The standards leave things open. ECMA-404 defines the syntax only. RFC 8259 adds interoperability advice and still leaves choices to the implementer: what to do with duplicate keys, how large a number may be, how deep nesting can go. This parser makes those choices implicitly.

Recursive descent has a depth limit. Each nested array or object is another function call, so a document nested deeply enough will overflow the call stack. Production parsers either cap the depth or use an explicit stack.

Do not use this in production. JSON.parse is implemented in native code and heavily optimised. The reason to write your own is to understand the one you already have.

If you are curious to check out full code, here's the GitHub Repo.

✌️ Stay curious, Keep coding, Peace nerds!

Updated 9 October 2026: fixed a broken sentence, pointed the ECMA-404 link at the standard itself, and added the section on where this stops applying.

Building a spell checker

Aditya Negandhi — Fri, 09 Oct 2026 12:07:37 +0000

Hey fellow devs! 👋 Let me tell you about my recent adventure with the Levenshtein's Distance algorithm. You know those moments when you discover something that makes you go "Wow, that's actually pretty cool?" This was one of those moments.

The idea in one line: a spell checker is an edit-distance function plus a dictionary. Measure how many single-character edits separate the typed word from each known word, and suggest the closest ones.

The Discovery 🔍

There I was, grinding through DSA problems (like we all do), when I encountered the Levenshtein Distance algorithm. At first glance, it seemed like just another dynamic programming problem to add to my interview prep arsenal. But as I dug deeper, I discovered something fascinating: this algorithm is actually the backbone of spell checkers! You know, that thing that saves us from embarrassing typos in MS Word?

The Lightbulb Moment 💡

I immediately thought, "What if I could actually see this algorithm in action?" Not just the input and output, but the whole process. That's when I decided to build a spell checker visualizer. Nothing fancy, just something to help me (and maybe others) understand how this algorithm thinks. You can check out the live demo here or explore the source code on GitHub.

The Algorithm: Understanding Levenshtein Distance

How It Works (Time Complexity: O(m*n))

Imagine you're comparing two words and want to know how many changes it takes to turn one word into another. Let's break it down using "wrld" and "world" as an example:

First, we create a grid (matrix) where:
- The first row represents the letters of the first word (plus an empty space)
- The first column represents the letters of the second word (plus an empty space)
We fill the first row and column with counting numbers (0,1,2,3...). This represents how many changes it would take to transform an empty string into each letter sequence.
Then comes the interesting part. For each cell in the grid, we look at the corresponding letters and ask: "Are these letters the same?"
- If they are SAME:
  - We copy the number from the diagonal upper-left cell
- If they are DIFFERENT:
  - We look at three nearby cells (up, left, and diagonal upper-left)
  - Take the smallest number among them
  - Add 1 to it
The number in the bottom-right cell gives us our final answer - the minimum number of changes needed.

Basic implementation of the algorithm:

function levenshteinDistance(str1: string, str2: string): number {
  const matrix: number[][] = [];

  // Matrix initialization
  for (let i = 0; i <= str1.length; i++) {
    matrix[i] = [i];
  }
  for (let j = 0; j <= str2.length; j++) {
    matrix[0][j] = j;
  }

  // The magic happens here
  for (let i = 1; i <= str1.length; i++) {
    for (let j = 1; j <= str2.length; j++) {
      if (str1[i - 1] === str2[j - 1]) {
        matrix[i][j] = matrix[i - 1][j - 1];
      } else {
        matrix[i][j] =
          Math.min(
            matrix[i - 1][j - 1], // substitution
            matrix[i][j - 1],     // insertion
            matrix[i - 1][j]      // deletion
          ) + 1;
      }
    }
  }

  return matrix[str1.length][str2.length];
}

Dictionary Implementation

Here's a simple example of how the dictionary structure works:

interface Dictionary {
  words: Set<string>;
}

const dictionary: Dictionary = {
  words: new Set([
    'world',
    'hello',
    'programming',
    // ... more words
  ])
};

Building the Visualizer 🛠️

I grabbed my favorite tools for the job:

Vite + React: (because who doesn't love a speedy DX?)
TypeScript: (to keep my errors honest)
Tailwind CSS + ShadCn UI: (for that clean, modern look, yes with a dark mode!)

The core functionality is pretty straightforward:

User types some text
The app spots the misspelled words
Here's the cool part, it shows the Levenshtein matrix for each suggestion!

Visualization of the algorithm:

Alternative Approaches

While Levenshtein Distance is great, there are other spell-checking algorithms worth mentioning:

Damerau-Levenshtein Distance: Handles transposition of adjacent characters
Soundex: Matches words that sound similar
N-gram similarity: Useful for handling larger texts and finding similar phrases

Where this stops applying

Comparing against every word does not scale. The matrix costs O(m*n) per pair, and a naive checker runs it against the whole dictionary for every typo. That is fine for a hardcoded word list and far too slow for a real one. The standard fix is to index the dictionary so most words are never compared, for example with a BK-tree.

Plain Levenshtein gets common typos wrong. Swapping two adjacent letters ("teh") counts as two edits, so it can rank a worse suggestion first. It also knows nothing about which words are common. Peter Norvig's spelling corrector shows how much word frequency matters, in about twenty lines of Python.

It checks words, not sentences. "Their" for "there" is spelled correctly and will never be flagged. Context needs a language model, which is a different tool.

The Final Thoughts 💭

Is it basic? Absolutely! The dictionary is hardcoded, and it won't be replacing Grammarly anytime soon. But that was never the goal. I wanted to see the algorithm in action, to understand how it transforms "wrld" into "world" one edit at a time. And you know what? It works!

Learnings from this project 📚

Sometimes the simplest projects are the most satisfying. This wasn't about building the next big thing; it was about taking an algorithm from the realm of interview prep and watching it solve real problems.

Remember: Not every project needs to change the world. Sometimes, just understanding how things work is rewarding enough!

So here's to the small wins, the "aha" moments, and the joy of seeing algorithms come to life!

✌️ Stay curious, Keep coding, Peace nerds!

Updated 9 October 2026: stated the core idea up front, added sources, and added the section on where this stops applying.

Hoisting in Javascript

Aditya Negandhi — Fri, 09 Oct 2026 06:11:22 +0000

What is Hoisting?

Hoisting is the name for a JavaScript behavior where variable and function declarations act as if they were moved to the top of their containing scope. Nothing is physically moved: the engine registers every declaration in a scope before it runs any code in that scope, and the rest of this post is consequences of that one fact. This means that you can use variables and functions before they are declared in the code. Understanding hoisting is crucial for mastering JavaScript, as it can lead to unexpected results if not properly understood.

How Hoisting Works

In JavaScript, both variable declarations (using var, let, or const) and function declarations are hoisted. However, there are important differences in how they behave.

Variable Hoisting

When you declare a variable using var, the declaration is hoisted to the top of its function or global scope, but the assignment remains in place. This can lead to situations where a variable is undefined if accessed before its assignment.

console.log(myVar); // returns undefined
var myVar = 5;
console.log(myVar); // returns 5

In the example above, the first console.log outputs undefined because the declaration of myVar is hoisted, but the assignment myVar = 5 is not. The code is interpreted as:

var myVar;
console.log(myVar); // returns undefined
myVar = 5;
console.log(myVar); // returns 5

Function Hoisting

Function declarations are fully hoisted, meaning you can call a function before it is defined in the code. This is because the entire function declaration is hoisted to the top of its scope.

greet(); // returns "Hello, World!"

function greet() {
  console.log("Hello, World!");
}

In this case, the function greet can be called before its declaration because the entire function is hoisted to the top.

Let and Const Hoisting

Unlike var, variables declared with let and const are also hoisted, but they are not initialized. Accessing them before their declaration results in a ReferenceError.

// returns ReferenceError: Cannot access 'myLet' before initialization
console.log(myLet);
let myLet = 10;

// returns ReferenceError: Cannot access 'myConst' before initialization
console.log(myConst);
const myConst = 20;

In this example, both myLet and myConst throw a ReferenceError because they are in a "temporal dead zone" from the start of the block until their declaration.

Implications of Hoisting

Understanding hoisting is essential for avoiding common pitfalls in JavaScript. Here are a few key takeaways:

Always Declare Variables: To avoid confusion, always declare your variables at the top of their scope.
Function Declarations vs. Expressions: Remember that function declarations are hoisted with their body, but for a function expression (including arrow functions) only the variable is hoisted, not the function assigned to it.

// returns TypeError: square is not a function
console.log(square(5)); 

var square = function (num) {
  return num * num;
};

In this case, the square variable is hoisted, but since it is a function expression, it is not initialized until the assignment is reached, leading to a TypeError.

Wrapping Up

If you are wondering why the functions with function declaration are hoisted and why var func = function() {} or func() => {} are not hoisted, you can check out this post where I have discussed how JS execution engine reserves memory for the code. In short, if declaration is made using the function keyword, the engine stores entire chunk of that function definition along with the reference which allows us to call the function before definition at runtime while in other cases, memory is initially undefined until execution context reaches its definition.

Where this stops applying

In modern code hoisting rarely bites. With let, const, and ES modules, using a name too early throws immediately instead of quietly giving you undefined. The confusing cases above are mostly var cases, and most codebases have stopped writing var.

"Moved to the top" is a teaching model. The specification never moves code. It describes environment records that are filled in before execution starts. The model predicts the right output, but it will mislead you if you take it literally, for example about where a let variable "is" during its dead zone.

Classes behave like let. A class declaration is hoisted but uninitialized, so using it before its definition is a ReferenceError. This post does not cover that case.

The rule that makes all of this a non-issue: declare before use, prefer const, and let a linter flag the rest.

✌️ Stay curious, Keep coding, Peace nerds!

Updated 9 October 2026: reworded the definition to match the specification, fixed a dead link, added sources, and added the section on where this stops applying.

How Javascript Works

Aditya Negandhi — Fri, 09 Oct 2026 06:08:42 +0000

Javascript is a Synchronous and Single Threaded language. Meaning that it executes one line of code at a time and in the order that it is written. It cannot run in parallel.

The model this post builds: every piece of JavaScript runs inside an execution context, which is created in two passes. First the engine sets aside memory for every declaration, then it runs the code. Once you can trace those two passes by hand, hoisting, scope, and the call stack stop being surprising.

Execution Context

Everything in Javascript happens inside an execution context.

Execution context consists of 2 main parts - Variable Environment and Execution Stack.

Variable Environment

Variable Environment is a collection of variables that are available to the code. It is created when the code is executed and destroyed when the execution is finished.

Execution Stack

Execution Stack is a data structure that keeps track of the order in which the code is executed. It is a stack of functions that are called when the code is executed.

Let's look at how JS is executed under the hood

Now that we have a basic understanding of how Javascript works, here is its execution engine at work on an example.

lets take this JS code as an example and look how it is executed by JS engine:

var n = 2;

function square(num) {
  var ans = num * num;
  return ans;
}

var squareOfN = square(n); // returns 4

Remember that we said everything in JS happens inside an execution context. So, the first step JS engine takes is to create an execution context of the code.

Now we know that the execution context consists of 2 main parts - Variable Environment and Execution Stack.

There are 3 phases in the execution of JS code:

Phase 1 - Memory Creation Phase

In this phase, JS engine reserves the memory for all the variables and functions in the code. It does not store the actual values inside that variable just yet. Instead, it initializes the defined variable with undefined value initially.

at this point our execution context looks like this:

Now that the required memory is reserved, the next phase is called Execution Phase.

Phase 2 - Execution Phase

In this phase, JS engine executes the code line by line. It starts with the first line of code and executes it one by one. It now updates the initially reserved memory which was set to undefined with the actual value of the variable.

When the code execution reaches to the function call, a new execution context is created inside of current context.
Now, after creating new execution context and computing the square, the ans variable is returned to the parent context which will then store that value in the squareOfN variable.

Phase 3 - Garbage Collection Phase

After the execution of a function is complete, the context created for it will be destroyed and if we call same function again, entire execution cycle repeats. Execution cycle looks like this:

How JS engine handles the code execution

Now that we have an understanding of the brute force way fo JS execution, lets look at how it is executed in a more practical way by the JS engine.

The JS engine is a complex system that is responsible for executing the code. The most widely used one is V8, written in C++, which powers Chrome and Node.js. Firefox and Safari ship their own engines, SpiderMonkey and JavaScriptCore, and all of them follow the same ECMAScript specification.

JS engine uses a stack to keep track of the order in which the code is executed. It is a data structure that stores the execution context of each function call. When a function is called, it is pushed onto the stack. When the function returns, the context is popped off the stack.

The call stack also has a core component called Global Execution Context. This is the context that is used to execute the code outside of any function. It is the initial context that is created when the code is executed first. After completion of every function call in the stack, control of execution returns to the Global Execution Context which then runs further code.

Where this stops applying

This is a mental model, not how V8 is built. Real engines parse lazily, start in an interpreter, and compile hot functions to machine code while the program runs. The two-pass picture predicts what your code will output. It does not describe what the engine is doing internally.

Garbage collection is not a phase after each function. I drew it as phase 3 to keep the cycle simple. In practice memory is reclaimed by a collector that runs on its own schedule, whenever values are no longer reachable. A closure can keep a function's variables alive long after the function has returned.

Asynchronous code is missing. "Single threaded" is true of the call stack, but timers, promises, and network calls are handled by the event loop and its queues, which this post does not cover. That is the natural next thing to read about.

Wrapping Up

The habit worth keeping: when a piece of JavaScript surprises you, trace it by hand. Write down what is in memory after the first pass, then step through the second pass one line at a time. Most "weird" behaviour stops being weird by line three.

✌️ Stay curious, Keep coding, Peace nerds!

Updated 9 October 2026: corrected the description of JavaScript engines, added sources, and added the section on where this stops applying.

Understanding Big O

Aditya Negandhi — Fri, 09 Oct 2026 06:08:37 +0000

Big O notation answers one question: when the input gets bigger, how much more work does the algorithm do? It ignores how fast your machine is and looks only at the shape of the growth. Here are the four shapes you will meet most often, each with a JavaScript example.

O(n): The Linear Path

Imagine you have a list of numbers and you need to find a specific number. You check each number one by one until you find the target. This is O(n), where the execution time of an algorithm grows linearly with the size of the input data.

let nums = [1, 2, 3, 4, 5];
let target = 4;
for (let i = 0; i < nums.length; i++) {
    if (nums[i] === target) {
        return i;
    }
}

In this example, your search time increases directly with the number of elements in the array. Simple and straightforward!

O(1): The Constant Time

Now, imagine you need to access a specific element in an array by its index. This is O(1), where the execution time remains constant regardless of the input size.

let nums = [1, 2, 3, 4, 5];
let index = 2;
let value = nums[index]; // Should return '3'

Here, you instantly access the element without any extra effort. Efficient and swift!

O(n^2): The Quadratic Time

Picture yourself needing to compare every pair of elements in a list to find a specific condition. This is O(n^2), where the execution time grows quadratically with the input size.

let nums = [1, 2, 3, 4, 5];
let target = 6;
// Finding the indices of two numbers that add up to the target
for (let i = 0; i < nums.length; i++) {
    for (let j = i+1; j < nums.length; j++) {
        if (nums[i] + nums[j] === target) {
            return [i, j];
        }
    }
}

The inner loop runs for every step of the outer loop, so the number of comparisons grows with the square of the input. Double the array and the work roughly quadruples.

O(n log n): The Log-Linear Path

Consider the scenario where you need to sort a list of numbers. Many efficient sorting algorithms, like Merge Sort and Quick Sort, have an average time complexity of O(n log n). JavaScript's own Array.prototype.sort is in this class too; V8 implements it with TimSort. This means the execution time grows in a log-linear fashion with the size of the input data.

let nums = [5, 3, 8, 4, 2];
nums.sort((a, b) => a - b);
// Should return [2, 3, 4, 5, 8]

In this example, the sorting operation involves dividing the list and merging it back, resulting in a log-linear time complexity. It's more efficient than O(n^2) but more complex than O(n).

What the classes mean at real sizes

The names are abstract until you put numbers in. This is the count of basic steps for each class as the input grows:

Input size (n)	O(1)	O(n)	O(n log n)	O(n^2)
10	1	10	33	100
1,000	1	1,000	9,966	1,000,000
1,000,000	1	1,000,000	19,931,569	1,000,000,000,000

At ten items nothing matters. At a million, the quadratic algorithm does a million times more work than the linear one. That gap is the whole reason the notation exists.

Where this stops applying

Big O hides constants. An O(n) algorithm with a slow step can lose to an O(n^2) one on small inputs. For arrays of a few dozen items, the simple nested loop is often the faster and clearer choice.

It describes growth, not time. Cache behaviour, memory allocation, and the engine's optimiser decide real speed. When performance matters, measure with real data instead of reasoning from the notation alone.

This post covers four classes and only time. O(log n) (binary search), exponential time, and space complexity are missing, and worst case versus average case is only mentioned in passing.

The rule I use: look at the loops. One loop over the input is O(n), a loop inside a loop is O(n^2), and anything that halves the problem each step earns a log.

If you want to learn more about Data Structures and Algorithms, check out my GitHub Repo where I'm diving into Neetcode's blind 75 problems using JS.

✌️ Stay curious, Keep coding, Peace nerds!

Updated 9 October 2026: corrected the explanation of quadratic growth, added the table of step counts and sources, and added the section on where this stops applying.