DEV Community: nyaomaru

Learn Trapping Rain Water, Top K Frequent and Selection Sort with Step-by-Step Visualization in DSA View View 👀👀

nyaomaru — Wed, 09 Sep 2026 12:48:25 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who has been obsessed with ramen lately. 😸🍜

Have you used DSA View View already? 👀👀

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous articles, we looked at problems like:

Two Sum
Binary Search
Bubble Sort
Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree
Number of Islands
Invert Binary Tree
Course Schedule

Visualizing execution logic changes mental models

nyaomaru

Aug 19

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

#dsa #typescript #opensource #learning

7 min read

Curated progression from stacks to recursion

nyaomaru

Aug 26

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀

#typescript #algorithms #opensource #dsa

9 min read

Readers praise the recursive swap explanation

nyaomaru

Sep 2

Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step Visualization in DSA View View 👀👀

#typescript #dsa #opensource #webdev

12 min read

This time, let's try three more problems:

Trapping Rain Water
Top K Frequent Elements
Selection Sort

These three problems introduce some very useful ways of thinking

Shrink a problem from both sides
Count first, then organize by frequency
Repeatedly select the next value

Once again, the implementations are not necessarily huge.

But there are several changing values that we need to keep in our heads.

So instead of only reading the final code,

Let's view what actually happens. 👀👀

🌧️ Trapping Rain Water

Let's start with Trapping Rain Water.

Suppose we have these heights

[0, 1, 0, 2, 1, 0, 1, 3]

If we draw them as walls, it looks roughly like this.

              █
      █       █
  █   █ █   █ █
-----------------
0 1 0 2 1 0 1 3

Rain falls from above.

Some water escapes.

But some water becomes trapped between taller walls.

For example

      █~~~~~~~█
  █~~~█~~~~~~~█
-----------------

So the question is

How much water can be trapped?

At first, I found this problem quite confusing. 😿

Because the amount of water above one position depends on walls somewhere else.

So what information do we actually need?

How Much Water Fits Above One Position?

Imagine this position

left wall     right wall
    █             █
    █      x      █
    █      █      █

The water level cannot be higher than the shorter side.

So the maximum possible water level is

Math.min(leftMax, rightMax);

Then we subtract the current height.

Conceptually:

water = min(leftMax, rightMax) - currentHeight

That's the basic idea.

But do we really need to calculate both sides again for every position?

No.

We can use two pointers.

Two Pointers

Here is the implementation.

function trap(height: number[]): number {
  let left = 0;
  let right = height.length - 1;

  let leftMax = 0;
  let rightMax = 0;

  let water = 0;

  while (left <= right) {
    if (height[left] <= height[right]) {
      if (height[left] >= leftMax) {
        leftMax = height[left];
      } else {
        water += leftMax - height[left];
      }

      left++;
    } else {
      if (height[right] >= rightMax) {
        rightMax = height[right];
      } else {
        water += rightMax - height[right];
      }

      right--;
    }
  }

  return water;
}

There are several important values.

left
right
leftMax
rightMax
water

This is exactly the kind of code where I understand every variable individually,

but then lose track of all of them together. 😹

Let's follow a smaller example.

[2, 0, 1, 3]

Start From Both Ends

At first

left = 0
right = 3

[2, 0, 1, 3]
 ↑        ↑
left    right

The heights are:

height[left]  = 2
height[right] = 3

Since

2 <= 3

we process the left side.

There is a wall with height 2.

leftMax = 2

Then move left.

[2, 0, 1, 3]
    ↑     ↑
   left right

Now We Can Trap Water

The current height is

But we already know there is a wall of height 2 on the left.

And the right side is currently at least as high as that.

So this position can hold

leftMax - height[left]
= 2

Therefore

water = 2

Move again.

[2, 0, 1, 3]
       ↑  ↑
      left right

Now

height[left] = 1
leftMax = 2

2 - 1 = 1

One more unit of water.

water = 3

Eventually we reach the final wall.

Done! 🎉

Why Can We Process the Shorter Side?

This part is the important idea.

Suppose

height[left] <= height[right]

Then we already know there is a wall on the right that is at least as tall as the current left wall.

So for the current left position, the limiting factor is the best wall we have seen from the left.

That's why we can safely calculate

leftMax - height[left];

without knowing every future wall.

The same logic works from the other side.

height[right] < height[left]

we process the right side using rightMax.

So the algorithm keeps shrinking the unknown area

L → → →     ← ← ← R

until everything has been processed.

Complexity

Each pointer only moves across the array once.

Time:  O(n)
Space: O(1)

👀 Let's View View It

This problem is a perfect example of why I like visualization.

The code contains

left
right
leftMax
rightMax
water

And they all change at different times.

When I only read

water += leftMax - height[left];

I might ask:

Why are we using leftMax here?
What is rightMax right now?
Why did we move left instead of right?
How much water have we already counted?
Which part of the array is still unprocessed?

😿

dsa-view-view.vercel.app

Step by step, we can actually watch the search area shrink.

L         R
↓         ↓
[2, 0, 1, 3]

    L     R
    ↓     ↓
[2, 0, 1, 3]

       L  R
       ↓  ↓
[2, 0, 1, 3]

And at the same time

leftMax
rightMax
water

keep changing.

The algorithm is really asking

Which side can I safely solve right now?

Then it solves that side and moves inward. 🌧️😸

🔢 Top K Frequent Elements

Next, let's find the Top K Frequent Elements.

Suppose we have

[1, 1, 1, 2, 2, 3]

and

k = 2

How often does each number appear?

1 → 3 times
2 → 2 times
3 → 1 time

So the two most frequent values are

[1, 2]

Simple enough.

But how should we implement it?

First, Count Everything

The first thing we need is frequency.

We can use a Map.

const frequency = new Map<number, number>();

Then count each value.

for (const num of nums) {
  frequency.set(num, (frequency.get(num) ?? 0) + 1);
}

For

[1, 1, 1, 2, 2, 3]

we get

frequency = {
  1 → 3
  2 → 2
  3 → 1
}

Nice.

But we still need the top K.

Of course, we could sort everything by frequency.

But there is another interesting approach.

Use Frequency as an Index

The maximum possible frequency is

nums.length

So we can create buckets.

const buckets: number[][] = Array.from({ length: nums.length + 1 }, () => []);

The index represents frequency.

For example

bucket[1] = values appearing 1 time
bucket[2] = values appearing 2 times
bucket[3] = values appearing 3 times

For our example:

frequency = {
  1 → 3
  2 → 2
  3 → 1
}

the buckets become

index 0 → []
index 1 → [3]
index 2 → [2]
index 3 → [1]

That's pretty interesting. 👀👀

Instead of asking

What is the frequency of this number?

we reverse the relationship

Which numbers have this frequency?

Implementation

Here is the full implementation:

function topKFrequent(nums: number[], k: number): number[] {
  const frequency = new Map<number, number>();

  for (const num of nums) {
    frequency.set(num, (frequency.get(num) ?? 0) + 1);
  }

  const buckets: number[][] = Array.from({ length: nums.length + 1 }, () => []);

  for (const [num, count] of frequency) {
    buckets[count].push(num);
  }

  const result: number[] = [];

  for (let count = buckets.length - 1; count >= 0; count--) {
    for (const num of buckets[count]) {
      result.push(num);

      if (result.length === k) {
        return result;
      }
    }
  }

  return result;
}

Let's follow it.

Step 1: Build the Frequency Map

Start

frequency = {}

Read the first 1. And another one and another...

1 → 1
1 → 2
1 → 3

Then 2. And another one.

1 → 3
2 → 1
2 → 2

Finally 3.

1 → 3
2 → 2
3 → 1

Done.

Step 2: Put Values Into Buckets

Now

buckets[count].push(num);

For

1 → 3

we do

buckets[3].push(1)

For

2 → 2

we do

buckets[2].push(2)

And

3 → 1

becomes

buckets[1].push(3)

0: []
1: [3]
2: [2]
3: [1]

Step 3: Read From Highest Frequency

We want the most frequent values.

So don't start at 0. Start from the end.

3 → [1]
2 → [2]
1 → [3]

Take 1.

result = [1]

We still need one more. Move down.

Take 2.

result = [1, 2]

Now

result.length === k

So return.

Done! 🎉

Why Is This Interesting?

I like this solution because the second structure changes our perspective.

The Map says

value → frequency

The buckets say

frequency → values

Same information. But different direction.

And suddenly finding the most frequent values becomes easy.

We just walk backward through the buckets.

Complexity

We count every number once.

We distribute every unique number into a bucket.

Then we walk through the buckets.

Time:  O(n)
Space: O(n)

👀 Let's View View It

There are two transformations happening here.

First

nums
 ↓
frequency Map

Then

frequency Map
 ↓
buckets

Then

buckets
 ↓
result

Reading the final implementation, it can be easy to miss why we're building two different data structures.

dsa-view-view.vercel.app

With the runtime visible, we can follow the data changing shape.

[1, 1, 1, 2, 2, 3]
        ↓ count
1 → 3
2 → 2
3 → 1
        ↓ bucket
1: [3]
2: [2]
3: [1]
        ↓ highest first
[1, 2]

That's the part I like.

We don't magically find the top K.

We reorganize the information until the answer becomes easy to read. 🔢😸

👉 Selection Sort

Finally, let's sort something again!

We already looked at Bubble Sort in a previous article.

This time, let's try Selection Sort.

Suppose we have

[5, 3, 4, 1, 2]

We want

[1, 2, 3, 4, 5]

Selection Sort follows a very simple idea

Find the smallest remaining value and move it to the front.

Then repeat.

First Pass

Start

[5, 3, 4, 1, 2]
 ↑
 i

Assume the first value is currently the smallest.

minIndex = 0

Then scan everything to the right.

5 vs 3

3 is smaller.

So:

minIndex = 1

Then:

3 vs 4

No change.

Then

3 vs 1

1 is smaller.

minIndex = 3

Finally

1 vs 2

Still 1.

So the smallest value is at index 3.

Swap

[5, 3, 4, 1, 2]
 ↑        ↑
 i       min

↓

[1, 3, 4, 5, 2]

Now the first position is finished.

[1 | 3, 4, 5, 2]
 ↑
sorted

Repeat

Next, start from index 1.

[1 | 3, 4, 5, 2]
     ↑
     i

Find the smallest value in

[3, 4, 5, 2]

That's 2.

Swap.

[1, 2 | 4, 5, 3]

Again.

Find the smallest remaining value.

Eventually

[1, 2, 3, 4, 5]

Sorted! 🎉

Implementation

function selectionSort(nums: number[]): number[] {
  for (let i = 0; i < nums.length - 1; i++) {
    let minIndex = i;

    for (let j = i + 1; j < nums.length; j++) {
      if (nums[j] < nums[minIndex]) {
        minIndex = j;
      }
    }

    if (minIndex !== i) {
      [nums[i], nums[minIndex]] = [nums[minIndex], nums[i]];
    }
  }

  return nums;
}

There are two important indexes.

i
minIndex

And also

which searches through the unsorted area.

Why Is It Called Selection Sort?

Because each pass selects the smallest remaining value.

Find smallest
  ↓
Select it
  ↓
Move it to the front
  ↓
Repeat

That's basically the whole algorithm.

Complexity

For every position, we search through the remaining values.

Time: O(n²)

We sort the array in place.

Space: O(1)

Selection Sort is not something I would normally choose for sorting a huge production dataset. 😹

But as a learning algorithm, it is wonderfully visual.

👀 Let's View View It

The implementation contains nested loops.

for (let i = 0; i < nums.length - 1; i++) {
  let minIndex = i;

  for (let j = i + 1; j < nums.length; j++) {

Reading it, I might lose track of:

Which area is already sorted?
Where is i?
Where is j?
What does minIndex currently point to?
When exactly does the swap happen?

dsa-view-view.vercel.app

When we visualize it, the basic pattern becomes obvious.

[5, 3, 4, 1, 2]
          ↑
       smallest

[1 | 3, 4, 5, 2]
              ↑
           smallest

[1, 2 | 4, 5, 3]

The algorithm is continuously growing a finished area from left to right.

That's Selection Sort.

Pick the smallest remaining value.

Put it next. And repeat. 🍥😸

🧠 What Did We Actually Learn?

Again, these three problems look completely different.

But each one introduces a useful way of thinking.

Trapping Rain Water

Use information from both sides to decide which part can already be solved safely.

Which side do I know enough about right now?

Top K Frequent Elements

Sometimes counting the data is only the first step.

Reorganize it into a structure where the answer becomes easy to retrieve.

Can I reorganize this information around what I actually need?

Selection Sort

Build the answer one permanent position at a time.

What value belongs in this position next?

So this time we saw

Two pointers
Frequency buckets
Selection

Three different mental models again.

And just like the previous problems, the difficult part is often not the syntax.

It's the changing state.

Which pointer moved?
What is the maximum now?
What is inside the Map?
Which bucket changed?
Where is minIndex?
Which part is already finished?

That's a lot to keep in our heads.

So instead, I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Trapping Rain Water with two pointers
Top K Frequent Elements with frequency buckets
Selection Sort

And more importantly, we followed how their state changes while they run.

For Trapping Rain Water, we watched two pointers move inward while leftMax, rightMax, and water changed.

left →       ← right

For Top K Frequent Elements, we watched the same data change representation.

array
  ↓
frequency Map
  ↓
buckets
  ↓
result

For Selection Sort, we watched the sorted area grow one position at a time.

This is exactly the kind of thing I built DSA View View for.

dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

See you in the next article!

Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step Visualization in DSA View View 👀👀

nyaomaru — Wed, 02 Sep 2026 14:54:12 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who is surprised by how cold it is in the Netherlands even though it’s still summer. 😸

Have you used DSA View View already? 👀👀

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous articles, we looked at problems like:

Two Sum
Binary Search
Bubble Sort
Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

Visualizing execution logic changes mental models

nyaomaru

Aug 19

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

#dsa #typescript #opensource #learning

7 min read

Curated progression from stacks to recursion

nyaomaru

Aug 26

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀

#typescript #algorithms #opensource #dsa

9 min read

This time, let's try three more classic problems:

Number of Islands
Invert Binary Tree
Course Schedule

These three problems introduce some very useful ways of thinking:

Explore connected things
Transform a tree with recursion
Resolve dependencies in the right order

The implementations are not huge.

But the runtime can become surprisingly difficult to hold in our heads.

So let's view what actually happens. 👀

Let's learn together! 😸

🏝️ Number of Islands

Let's start with Number of Islands.

Suppose we have this grid:

1 means land. 🏝️

0 means water. 🌊

Land connected vertically or horizontally belongs to the same island.

So how many islands are there?

Let's look at the first group.

1 1
1

These cells are connected.

So they form one island.

On the right side

    1
  1 1

Those cells are also connected.

So the answer is 2.

Nice! 🏝️🏝️

But how do we make the code understand that several 1s belong to the same island?

Find One Land, Then Explore All Connected Land

The basic idea is

When we find a new 1, count one island and visit all land connected to it.

Let's use this implementation.

function numIslands(grid: string[][]): number {
  let islands = 0;

  const visit = (row: number, col: number): void => {
    if (row < 0 || col < 0) return;
    if (row >= grid.length || col >= grid[row].length) return;
    if (grid[row][col] !== "1") return;

    grid[row][col] = "0";
    visit(row + 1, col);
    visit(row - 1, col);
    visit(row, col + 1);
    visit(row, col - 1);
  };

  for (let row = 0; row < grid.length; row++) {
    for (let col = 0; col < grid[row].length; col++) {
      if (grid[row][col] === "1") {
        islands++;
        visit(row, col);
      }
    }
  }

  return islands;
}

There are two important parts.

First, we scan the grid

for (let row = 0; row < grid.length; row++) {
  for (let col = 0; col < grid[row].length; col++) {

Then, when we find land

if (grid[row][col] === "1") {
  islands++;
  visit(row, col);
}

We count a new island.

But then visit() does something important.

It removes all land connected to that island from future consideration.

Why Do We Change `1` to `0`?

Inside visit() we have

grid[row][col] = "0";

At first, changing land into water looks a little strange. 😿

But here, 0 really means

We already visited this land.

Let's follow a tiny example.

1 1
1 0

We start at the top-left. And we found land! So

islands = 1

Then

visit(0, 0);

Inside visit(), we mark it as visited.

0 1
1 0

Then we visit the four directions

down
up
right
left

Going down finds another 1.

0 1
1 0
↑

So we visit it too.

0 1
0 0

Going right from the original cell also finds land.

Visit it.

0 0
0 0

Now the whole connected island has disappeared from our search.

When the outer loops continue, there is no 1 left in that island to count again.

That's the key idea.

Count once, then mark the whole connected area as visited.

Why Four Recursive Calls?

We use

visit(row + 1, col);
visit(row - 1, col);
visit(row, col + 1);
visit(row, col - 1);

That means

        up
         ↑
left ← current → right
         ↓
        down

Each visited cell asks

Is there more land next to me?

And every newly discovered land cell asks the same question again.

This continues until we reach:

water
outside the grid
land we already visited

Those cases stop the recursion.

The Base Cases

These lines protect us

if (row < 0 || col < 0) return;
if (row >= grid.length || col >= grid[row].length) return;
if (grid[row][col] !== "1") return;

So,

If we walk outside the grid, stop.
If we reach water, stop.
If we reach a cell we already changed to 0, stop.

Otherwise, continue exploring.

Let's Follow Two Islands

Consider

1 1 0
0 0 1
0 1 1

The scan begins at the top-left.

Found land.

islands = 1

visit() removes everything connected to it.

0 0 0
0 0 1
0 1 1

The loops continue.

Eventually we reach

Another 1.

islands = 2

And visit() explores that entire connected area.

0 0 0
0 0 0
0 0 0

Done!

2 islands

🎉

Complexity

Every cell is processed at most a small number of times.

If the grid has m rows and n columns

Time:  O(m × n)

In the worst case, the recursive call stack may grow with the number of land cells.

Space: O(m × n)

👀 Let's View View It

This is one of those algorithms where the final code is pretty small.

But while reading it, there are a lot of things moving at once

row
col
grid
islands
recursive calls

And then suddenly we see

grid[row][col] = "0";

Why did that cell disappear?
Which recursive call are we inside?
Which cells belong to the current island?
Where will the outer loop continue after recursion finishes?

That is a lot to simulate mentally. 😿

dsa-view-view.vercel.app

When we view it step by step, the idea becomes much more visual.

Find land
  ↓
islands++
  ↓
visit connected land
  ↓
mark it visited
  ↓
expand up / down / left / right
  ↓
return to scanning
  ↓
find next island

Instead of thinking about recursion first, I like to think about it like this

Find one island, paint the whole island away, then keep searching.

🏝️😸

🌳 Invert Binary Tree

Next, let's invert a binary tree.

Suppose we have

We want to change

Every left child becomes the right child.

Every right child becomes the left child.

Simple, right?

Well, the final implementation is also surprisingly small.

function invertTree(root: TreeNode | null): TreeNode | null {
  if (root === null) return null;

  const left = invertTree(root.left);
  const right = invertTree(root.right);

  root.left = right;
  root.right = left;

  return root;
}

That's almost suspiciously short. 👀

Go Down First

Let's use a smaller tree.

    1
   / \
  2   3

We start at node 1.

But we don't swap immediately.

First,

const left = invertTree(root.left);

So we go to node 2.

Node 2 also tries to invert its left child.

But there is no child.

if (root === null) return null;

returns null.

The same thing happens on the right side of node 2.

Now node 2 has

left = null
right = null

root.left = right;
root.right = left;

does not visibly change anything.

Node 2 returns.

Then node 1 explores its right subtree.

Node 3 also has no children, so it returns after the same process.

Only then do we come back to node 1.

Now

left = 2
right = 3

And we do

root.left = right;
root.right = left;

    1
   / \
  2   3

becomes 👇

    1
   / \
  3   2

Done! 🎉

The Important Part: The Swap Happens on the Way Back

This is what makes the recursive solution interesting.

The function first goes down.

1
↓
2
↓
null

Then it comes back.

Later it explores the other side.

1
↓
3
↓
null

And after both children have returned, the current node swaps them.

So the flow is more like

Go left
  ↓
Invert left subtree
  ↓
Go right
  ↓
Invert right subtree
  ↓
Swap the returned subtrees
  ↓
Return current node

The tree transformation is built while recursion unwinds.

A Slightly Bigger Example

Let's look at

We start at 4.

invertTree(4)

Then

invertTree(2)

Then

invertTree(1)

Node 1 returns.

Then node 3 returns.

Now node 2 has

left = 1
right = 3

Swap them.

    2
   / \
  3   1

Then recursion returns to 4.

The right subtree rooted at 7 is also processed.

Finally node 4 receives

left = inverted subtree rooted at 2
right = inverted subtree rooted at 7

and swaps them.

The final tree becomes

The interesting thing is that each node only needs to know about its own two children.

It doesn't need to understand the whole tree.

Complexity

We visit every node once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

For a balanced tree

O(log n)

In the worst case

O(n)

👀 Let's View View It

This is exactly where recursion can become difficult to mentally simulate.

The code says

const left = invertTree(root.left);
const right = invertTree(root.right);

Then

root.left = right;
root.right = left;

But my brain immediately starts asking:

Which root are we talking about now?
Did node 2 already swap?
Are we still going down?
Or are we coming back up?
What does left contain at this moment?

😿

dsa-view-view.vercel.app

When we step through the runtime, we can separate two different movements.

The final code is short.

But the actual runtime has a rhythm 🎵

Go down
↓
Return
↓
Swap
↓
Return
↓
Swap

Once I can see that rhythm, the recursive solution feels much less magical. 🌳😸

🎓 Course Schedule

Finally, let's look at Course Schedule.

This one is a little more difficult.

Suppose we have three courses

0
1
2

And the prerequisites are

[1, 0]
[2, 1]

That means

To take course 1, finish course 0 first.
To take course 2, finish course 1 first.

So the dependency looks like

0 → 1 → 2

Can we finish all courses?

Yes.

We can take them in this order 0 → 1 → 2.

Easy.

But what if the dependencies look like this?

0 → 1
↑   ↓
└── 2

Now

0 needs 2
1 needs 0
2 needs 1

Everyone is waiting for someone else.

We can never start.

That is a cycle.

And if there is a cycle, we cannot finish all courses.

Build the Graph

Here is the implementation:

function canFinish(numCourses: number, prerequisites: number[][]): boolean {
  const graph: number[][] = Array.from({ length: numCourses }, () => []);
  const indegree: number[] = Array(numCourses).fill(0);

  for (const [course, prerequisite] of prerequisites) {
    graph[prerequisite].push(course);
    indegree[course]++;
  }

  const queue: number[] = [];
  for (let course = 0; course < numCourses; course++) {
    if (indegree[course] === 0) queue.push(course);
  }

  let completed = 0;
  for (let head = 0; head < queue.length; head++) {
    const course = queue[head];
    completed++;

    for (const next of graph[course]) {
      indegree[next]--;
      if (indegree[next] === 0) queue.push(next);
    }
  }

  return completed === numCourses;
}

There are a few moving parts here.

graph
indegree
queue
completed

This is exactly the kind of algorithm where every individual line makes sense.

but the whole thing can still feel confusing. 😿

Let's break it down.

What Is `graph`?

For

0 → 1 → 2

we want to know

After I finish this course, which courses become closer to being available?

graph[0] = [1]
graph[1] = [2]
graph[2] = []

That means

Finish 0
↓
course 1 is affected

Finish 1
↓
course 2 is affected

We build that here

graph[prerequisite].push(course);

What Is `indegree`?

indegree tells us how many prerequisites a course is still waiting for.

For

0 → 1 → 2

we have

course 0: 0 prerequisites
course 1: 1 prerequisite
course 2: 1 prerequisite

indegree = [0, 1, 1]

Course 0 is special. Because it does not need anything before it.

So we can start there immediately.

Start With Courses That Need Nothing

We build the queue

for (let course = 0; course < numCourses; course++) {
  if (indegree[course] === 0) queue.push(course);
}

For our example

indegree = [0, 1, 1]

Only course 0 has zero prerequisites.

queue = [0]

This means

Course 0 is currently available.

Finish Course 0

Take

course = 0

Then

completed++;

completed = 1

Now look at courses depending on 0.

graph[0] = [1]

Course 1 was waiting for one prerequisite.

But course 0 is now complete.

indegree[1]--;

Then

indegree[1] = 0

Now course 1 needs nothing.

So we add it to the queue.

queue = [0, 1]

Finish Course 1

course = 1

Now

completed = 2

Course 2 depends on 1.

indegree[2]: 1 → 0

Add it to the queue.

queue = [0, 1, 2]

Finish Course 2

Finally

course = 2

completed = 3

And

numCourses = 3

Therefore

completed === numCourses; // true

We can finish everything! 🎉

Why Does This Detect a Cycle?

Now let's try

0 → 1
↑   ↓
└── 2

Every course has one prerequisite.

indegree = [1, 1, 1]

We try to build the initial queue.

if (indegree[course] === 0)

But there is no course with indegree 0.

So, nothing can start.

Therefore

completed = 0

And,

0 === 3 // false

We cannot finish the courses.

Another Example

Suppose

0 → 2
1 → 2
2 → 3

Course 2 needs both 0 and 1.

indegree = [0, 0, 2, 1]

The initial queue is

queue = [0, 1]

Finish 0.

indegree[2]: 2 → 1

Course 2 is still waiting.

So don't add it yet.

Finish 1.

indegree[2]: 1 → 0

Now course 2 is ready.

queue = [0, 1, 2]

Finish 2.

indegree[3]: 1 → 0

Now

queue = [0, 1, 2, 3]

Everything can be completed.

This is the key idea

When all prerequisites for a course are resolved, that course becomes available.

Why Use `head` Instead of `shift()`?

The queue is processed like this

for (let head = 0; head < queue.length; head++) {
  const course = queue[head]

Instead of repeatedly doing

queue.shift();

we keep an index pointing to the next item to process.

So the queue can grow while we iterate through it.

For example

queue = [0]

process 0
↓
queue = [0, 1]

process 1
↓
queue = [0, 1, 2]

head simply moves forward.

0 → 1 → 2
↑
head

Then

0 → 1 → 2
    ↑
   head

Then

0 → 1 → 2
        ↑
       head

Complexity

V = number of courses
E = number of prerequisite relationships

We build the graph once and process every course and edge.

Time: O(V + E)
Space: O(V + E)

👀 Let's View View It

This is probably the most interesting visualization of the three.

Because there are several things changing together.

graph
indegree
queue
head
completed

If I only read

indegree[next]--;
if (indegree[next] === 0) queue.push(next);

I understand the syntax.

But I may still ask:

Why did this course become available now?
Which prerequisite was removed?
Why is this course still not in the queue?
What does completed tell us?
Where exactly does the cycle get stuck?

dsa-view-view.vercel.app

When we view the runtime, we can watch the dependencies disappear.

0 → 1 → 2

indegree = [0, 1, 1]
queue = [0]

       ↓ finish 0

indegree = [0, 0, 1]
queue = [0, 1]

       ↓ finish 1

indegree = [0, 0, 0]
queue = [0, 1, 2]

       ↓ finish 2

completed = 3

The code stops feeling like mysterious bookkeeping.

We're really doing one simple thing:

Keep taking courses that are ready, and make their dependent courses closer to being ready.

If eventually every course becomes ready

completed === numCourses

there is no blocking cycle.

If some courses never become ready

completed < numCourses

something is stuck in a cycle. 🎓😸

🧠 What Did We Actually Learn?

These three problems look very different.

But each one teaches a useful way of thinking.

Number of Islands

When you find one part of a connected group, explore the entire group before continuing.

What else is connected to this?

Invert Binary Tree

Let recursive calls solve the smaller subtrees first, then transform the current node using their results.

Can my children finish their work before I change this node?

Course Schedule

Process things that have no unresolved dependencies, then use them to unlock more work.

What can I safely process right now?

The implementations are not very long.

But each one introduces a different mental model.

DFS on a grid
Recursive tree transformation
Topological sorting

And once again, the syntax is not really the hardest part.

The difficult part is keeping track of the changing state.

Where are we?
What changed?
What is waiting?
What has already been visited?
Which recursive call are we inside?

Sometimes I can read every line and still lose the thread somewhere in the middle. 😿

That's exactly when I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Number of Islands with recursive grid traversal
Invert Binary Tree with recursion
Course Schedule with topological sorting

And more importantly, we followed what changed while each algorithm was running.

For Number of Islands, we watched connected land disappear as it became visited.

1 → 0

For Invert Binary Tree, we watched recursive calls go down and the tree change while they returned.

go down
↓
come back
↓
swap

For Course Schedule, we watched prerequisites disappear and new courses enter the queue.

indegree--
↓
0 prerequisites
↓
queue.push()

This is exactly the kind of thing I built DSA View View for.

dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially when the implementation looks short, but your brain still says

Wait... what just changed? 😿

Seeing the runtime may make the idea much easier to follow.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

See you in the next article!

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀

nyaomaru — Wed, 26 Aug 2026 14:18:19 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who struggles to make game sounds. 😿

Have you used DSA View View already? 👀👀

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous article, we looked at:

Two Sum
Binary Search
Bubble Sort

Visualizing execution logic changes mental models

nyaomaru

Aug 19

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

#dsa #typescript #opensource #learning

7 min read

This time, let's try three more classic problems:

Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

These problems introduce three very different ideas:

Stack
Pointer manipulation
Recursion

And all three can become confusing when we only stare at the final code.

So let's view what actually happens. 👀

I'm still learning DSA too, so let's learn together! 😸

🥞 Valid Parentheses

Let's start with Valid Parentheses.

Suppose we have this string:

()[]{}

Every opening bracket has a matching closing bracket.

So this is valid. ✅

But this

([)]

is not valid. ❌

Why?

Because the brackets close in the wrong order.

(
  [
)
  ]

The [ should be closed before the (.

So how can we keep track of that order?

Use a Stack

A stack follows a simple rule:

The last thing we put in is the first thing we take out.

This is called LIFO (Last In / First Out)

Imagine stacking plates.

    🍽️  ← remove first
    🍽️
    🍽️

The last plate we put on top is the first one we can take.

Parentheses work in the same way.

If we see:

(
[
{

then the brackets must close in reverse order

}
]
)

So a stack is a very natural fit.

Here is the implementation:

function isValid(s: string): boolean {
  const stack: string[] = [];

  const pairs: Record<string, string> = {
    ")": "(",
    "]": "[",
    "}": "{",
  };

  for (const char of s) {
    if (char === "(" || char === "[" || char === "{") {
      stack.push(char);
      continue;
    }

    if (stack.length === 0) return false;

    const target = stack.pop();
    if (target !== pairs[char]) {
      return false;
    }
  }

  return stack.length === 0;
}

The important part is what happens to stack.

Let's use

([])

At first

stack = []

We see

It's an opening bracket.

Push it.

stack = ["("]

Next,

Push again.

stack = ["(", "["]

Then,

This is a closing bracket.

What should it close?

And what is currently on top of the stack?

Perfect. ✅

So we remove it.

stack = ["("]

Finally,

It should close

The top of the stack is also

Pop!

stack = []

We reached the end with an empty stack.

Valid! 🎉

What About an Invalid Example?

Consider

([)]

We start the same way.

(
↓
stack = ["("]

[
↓
stack = ["(", "["]

Then we find

A ) needs

But the top of our stack is

They don't match.

expected: (
actual:   [

So we immediately know the string is invalid.

Complexity

We walk through the string once.

Time:  O(n)
Space: O(n)

In the worst case, the stack may contain all opening brackets.

👀 Let's View View It

This is where the stack becomes much easier to understand.

When we only read.

stack.push(char);

And

stack.pop();

It can be easy to lose track of what is actually inside the stack.

Especially with something like.

({[]})

What is on top right now?

Which opening bracket are we trying to close?

Instead of remembering everything in our head, we can follow the stack changing step by step.

dsa-view-view.vercel.app

Conceptually, we can see:

(
↓
[(]

{
↓
[(, {]

[
↓
[(, {, []

]
↓
[(, {]

}
↓
[(]

)
↓
[]

That's the whole idea.

Remember the opening brackets, and always match the most recent one first.

Stack suddenly feels much less mysterious. 🥞😸

🔗 Reverse Linked List

Next, let's reverse a linked list.

Suppose we have

1 → 2 → 3 → 4 → 5

We want

5 → 4 → 3 → 2 → 1

At first glance, this sounds simple.

Just reverse it!

But linked lists are a little different from arrays.

With an array, the values live in positions like

0  1  2  3  4
↓  ↓  ↓  ↓  ↓
1  2  3  4  5

A linked list instead consists of nodes pointing to the next node.

1 → 2 → 3 → 4 → 5 → null

Each arrow matters. To reverse the list, we need to reverse those arrows.

1 ← 2 ← 3 ← 4 ← 5

And this is where things can get confusing.

Because if we change an arrow too early...

we may lose the rest of the list. 😿

Three Important Variables

A common iterative solution uses three variables

prev
current
next

Here is the implementation:

function reverseList(head: ListNode | null): ListNode | null {
  let prev: ListNode | null = null;
  let current = head;

  while (current !== null) {
    const next = current.next;

    current.next = prev;

    prev = current;
    current = next;
  }

  return prev;
}

It's short.

But there is a lot happening inside these few lines.

Let's follow it carefully.

We start with

1 → 2 → 3 → null

And

prev = null
current = 1

Step 1: Save the Next Node

First

const next = current.next;

next = 2

Why do we need this?

Because we're about to change

1 → 2

If we change that arrow without remembering 2, we lose access to the rest of the list.

So first

Save where we need to go next.

Step 2: Reverse the Arrow

Now

current.next = prev;

Originally

1 → 2

But prev is

null

So now

1 → null

The first arrow has been reversed.

Step 3: Move `prev`

prev = current;

prev = 1

Step 4: Move `current`

Finally

current = next;

We saved 2 earlier.

So now

current = 2

Our state looks like this

null ← 1    2 → 3 → null
       ↑    ↑
      prev current

Then we do exactly the same thing again.

Save:

next = 3

Reverse

2 → 1

Move

prev = 2
current = 3

Now

null ← 1 ← 2    3 → null
           ↑    ↑
          prev  current

One more time

next = null

Reverse

3 → 2

Move

prev = 3
current = null

And now

null ← 1 ← 2 ← 3
               ↑
              prev

The loop stops because

current === null

And prev is the new head.

return prev;

Done! 🎉

Complexity

We visit each node once.

Time:  O(n)
Space: O(1)

We don't create another linked list.

We only move a few pointers.

👀 Let's View View It

This is exactly the kind of code that I find difficult to understand by reading alone.

These four lines:

const next = current.next;
current.next = prev;
prev = current;
current = next;

look simple.

But when I first see code like this, my brain starts asking.

Wait.

- Where is current now?
- Did we lose next?
- Which arrow changed?
- What exactly does prev point to?

😿

dsa-view-view.vercel.app

When we visualize each step, we can actually follow the pointers moving.

prev      current
 ↓           ↓
null         1 → 2 → 3

      ↓↓↓

null ← 1     2 → 3
       ↑     ↑
      prev current

      ↓↓↓

null ← 1 ← 2     3
           ↑     ↑
          prev current

      ↓↓↓

null ← 1 ← 2 ← 3
               ↑
              prev

The algorithm becomes much simpler when we stop thinking of it as four mysterious assignments.

It's really just

Save next
  ↓
Reverse arrow
  ↓
Move prev
  ↓
Move current
  ↓
Repeat

Nice! 🔗😸

🌳 Maximum Depth of Binary Tree

Finally, let's look at a tree.

Consider this binary tree.

What is its maximum depth?

The longest path from the root to a leaf contains three nodes:

So the answer is.

How can we calculate that?

Think About a Smaller Tree

Suppose we are standing at one node.

We don't really need to understand the entire tree at once.

We only need to ask.

How deep is the left subtree?

How deep is the right subtree?

Then choose the larger one.

And add 1 for the current node.

That's exactly what this implementation does.

function maxDepth(root: TreeNode | null): number {
  if (root === null) {
    return 0;
  }

  const leftDepth = maxDepth(root.left);
  const rightDepth = maxDepth(root.right);

  return Math.max(leftDepth, rightDepth) + 1;
}

The important idea is

Math.max(leftDepth, rightDepth) + 1;

But recursion can feel strange.

When we call

maxDepth(root.left);

where does the current function go?

And how do all those calls eventually become one number?

Let's follow a small example.

We start at

But before 1 can know its depth, it asks its left child

maxDepth(2)

Node 2 asks

maxDepth(4)

Node 4 has no children.

So both sides eventually reach

null

And

maxDepth(null);

returns

Therefore node 4 can calculate

max(0, 0) + 1
= 1

Now we return to node 2.

Its left side has depth

Its right side is null

max(1, 0) + 1
= 2

Now return to node 1.

Eventually its right subtree also returns

So node 1 gets

leftDepth = 2
rightDepth = 1

And calculates

max(2, 1) + 1
= 3

Answer

🎉

The Interesting Part: Going Down and Coming Back Up

This is what makes recursion interesting.

First, the function calls go down the tree.

1
↓
2
↓
4
↓
null

But the answers are built while returning back up.

null → 0
4    → 1
2    → 2
1    → 3

So recursion isn't only

Keep calling the same function.

There are really two directions.

Go down
  ↓
Reach the base case
  ↓
Return values back up

The base case here is

if (root === null) {
  return 0;
}

Without it, the recursion would have no place to stop.

Complexity

Every node is visited once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

where h is the height of the tree.

For a balanced tree, that is roughly

O(log n)

In the worst case, if the tree looks like a linked list

the depth can become

O(n)

👀 Let's View View It

Recursion is probably my favorite example for visualization.

Because the final implementation is tiny

const leftDepth = maxDepth(root.left);
const rightDepth = maxDepth(root.right);

return Math.max(leftDepth, rightDepth) + 1;

But a lot is hidden inside those function calls.

When reading the code, it can feel like

maxDepth()
inside maxDepth()
inside maxDepth()
inside maxDepth()
...

Where are we now? 😿

dsa-view-view.vercel.app

When we step through the execution, we can follow both parts

Going down

1
↓
2
↓
4
↓
null

and then

Coming back

null → 0
↓
4 → 1
↓
2 → 2
↓
1 → 3

That makes the recursive idea much easier to see.

Ask the smaller subproblems for their answers, then use those answers to build the current answer.

🌳😸

🧠 What Did We Actually Learn?

These three problems look completely different.

But each one introduces a very useful way of thinking.

Valid Parentheses

Use a stack when the most recent item needs to be handled first.

What was the last thing I opened?

Reverse Linked List

When changing references, save what you still need before breaking the old connection.

Where do I need to go next before I change this pointer?

Maximum Depth of Binary Tree

Break a problem into smaller versions of the same problem.

Can I get the answers from my children and build my answer from them?

This is one reason I like learning these problems together.

The implementations are not very large.

But each one introduces a completely different mental model

Stack
Pointer
Recursion

And those mental models are much harder to learn than the syntax itself.

Sometimes the code tells us what happens.

But I also want to see how it happens.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Valid Parentheses with a stack
Reverse Linked List with pointer manipulation
Maximum Depth of Binary Tree with recursion

And more importantly, we followed the state while each algorithm was running.

We watched change the stack.

stack.push() / stack.pop()

We watched move through a linked list.

prev
current
next

And we watched recursive calls travel down a tree and return their answers back up.

This is exactly the kind of thing I built DSA View View for.

dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially if a solution feels like

I understand every line individually... but somehow I still don't understand the whole thing. 😿

Seeing the runtime may connect those pieces together.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

See you in the next article!

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

nyaomaru — Wed, 19 Aug 2026 14:43:44 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who dislikes crowded places, so I'm planning to take a quiet vacation in September. 🏝️

Have you used DSA View View already? 👀👀

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

But just introducing the tool is not enough.

Can it actually help us understand DSA?

In this article, we'll walk through three classic problems:

Two Sum
Binary Search
Bubble Sort

We'll first understand the algorithm, and then see what is actually happening with DSA View View.

Let's learn together! 😸

🗺️ Two Sum

Let's start with a very famous problem.

Given an array of numbers and a target value, find the indices of two numbers whose sum equals the target.

For example,

nums = [2, 7, 11, 15];
target = 9;

The answer is

[0, 1];

Because

2 + 7 = 9

Simple!

So, how should we find them? 🤔

Brute Force

The easiest approach is probably checking every possible pair.

function twoSum(nums: number[], target: number): number[] {
  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];
      }
    }
  }

  return [];
}

This works.

But if the array becomes large, we may need to compare a lot of pairs, right?

The time complexity is O(n²)

Can we avoid checking the same values again and again?

Yes.

Let's use a Map.

function twoSum(nums: number[], target: number): number[] {
  const seen = new Map<number, number>();

  for (let i = 0; i < nums.length; i++) {
    const current = nums[i];
    const need = target - current;

    if (seen.has(need)) {
      return [seen.get(need)!, i];
    }

    seen.set(current, i);
  }

  return [];
}

The important part is this 👇

const need = target - current;

Instead of asking

Which two numbers should I combine?

we ask

What number do I need to complete the target?

Let's follow the example.

At first

current = 2
target = 9

need = 9 - 2
     = 7

Have we already seen 7?

No.

So we remember 2.

seen = {
  2 → 0
}

current = 7
target = 9

need = 9 - 7
     = 2

Have we already seen 2?

Yes! 👀👀

seen = {
  2 → 0
}

return [0, 1];

Done!

Because we only need to walk through the array once, the time complexity becomes.

Time:  O(n)
Space: O(n)

👀 Let's View View It

The implementation is quite small.

But when I was first learning this pattern, this part still felt a little magical.

if (seen.has(need))

Where did need come from?
What is inside seen at this moment?
Why does checking the previous values solve the problem?

This is exactly where visualization helps.

dsa-view-view.vercel.app

With DSA View View, we can move through the runtime one step at a time and inspect how the values change.

2
↓
Need 7
↓
Remember 2
↓
7
↓
Need 2
↓
Found 2!
🎉

Now the Map is not just some mysterious trick.

We can actually follow the idea.

Remember what we have already seen, and check whether the value we need is there.

Nice! 😸

🔍 Binary Search

Next is Binary Search.

Suppose we have this sorted array

[1, 3, 5, 7, 9, 11, 13]

And we want to find

Of course, we could start from 1 and check every number.

1 → 3 → 5 → 7 → 9 → 11

That works.

But Binary Search does something smarter.

Instead of checking from the beginning, it checks the middle.

[1, 3, 5, 7, 9, 11, 13]
          ↑
         mid

Our middle value is 7.

We are looking for 11.

11 > 7

Because the array is sorted, we already know something very useful.

Everything on the left side of 7 is also smaller than 11.

So, we don't need that half anymore. 👋

[1, 3, 5, 7, 9, 11, 13]
             └───────┘
               search

Now we check the middle of the remaining range.

[9, 11, 13]
     ↑
    mid

And

11 === 11

Found it! 🎉

Here is the implementation.

function binarySearch(nums: number[], target: number): number {
  let left = 0;
  let right = nums.length - 1;

  while (left <= right) {
    const mid = Math.floor((left + right) / 2);

    if (nums[mid] === target) {
      return mid;
    }

    if (nums[mid] < target) {
      left = mid + 1;
    } else {
      right = mid - 1;
    }
  }

  return -1;
}

There are three important variables.

left
right
mid

They represent the current search range.

For our example, they start like this

left = 0
right = 6
mid = 3

[1, 3, 5, 7, 9, 11, 13]
 ↑        ↑          ↑
left     mid       right

Because

nums[mid] < target;

we move left.

left = mid + 1;

Now

[1, 3, 5, 7, 9, 11, 13]
             ↑   ↑   ↑
           left mid right

And 11 is found.

Why Is Binary Search Fast?

This is the interesting part.

Each step removes about half of the remaining candidates.

If there are 1,000 values, we don't necessarily need 1,000 checks.

It becomes roughly

1000
↓
500
↓
250
↓
125
↓
...

That's why Binary Search has

Time:  O(log n)
Space: O(1)

But there is one very important condition.

The data must be sorted.

Without sorted data, we cannot safely throw away half of the search range.

👀 Let's View View It

Binary Search is one of the algorithms that made me want a visualization tool in the first place.

The code itself is short

left = mid + 1;

right = mid - 1;

Easy.

But when learning it, I sometimes found myself thinking:

Wait... which part are we searching now? 😿

dsa-view-view.vercel.app

When we visualize left, mid, and right, the idea becomes much easier to follow.

We are not randomly changing three numbers.

We are continuously shrinking the search area.

███████████████

       ↓

        ███████

       ↓

          ███

       ↓

           █

That's Binary Search!

Cut the unnecessary half.

Then cut it again. And again. And again.

Until we find the answer. ✂️😸

🫧 Bubble Sort

Finally, let's sort something!

Consider this array.

[5, 1, 4, 2, 8];

We want.

[1, 2, 4, 5, 8];

Bubble Sort repeatedly compares two neighboring values.

If they are in the wrong order, it swaps them.

Let's look at the beginning.

[5, 1, 4, 2, 8]
 ↑  ↑

Compare

5 > 1

So swap them.

[1, 5, 4, 2, 8]

[1, 5, 4, 2, 8]
    ↑  ↑

Again

5 > 4

Swap!

[1, 4, 5, 2, 8]

And continue.

[1, 4, 5, 2, 8]
       ↑  ↑

5 > 2

Swap!

[1, 4, 2, 5, 8]

Eventually, larger values move toward the end of the array.

They kind of...

bubble up. 🫧

That's why it is called Bubble Sort.

Here is a simple implementation:

function bubbleSort(nums: number[]): number[] {
  for (let i = 0; i < nums.length - 1; i++) {
    for (let j = 0; j < nums.length - i - 1; j++) {
      if (nums[j] > nums[j + 1]) {
        [nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];
      }
    }
  }

  return nums;
}

We repeatedly compare

nums[j];

And

nums[j + 1];

and swap them when necessary.

After one full pass, the largest remaining value reaches its correct position near the end.

So on the next pass, we don't need to check that position again.

That's why the inner loop contains.

nums.length - i - 1;

Complexity

Bubble Sort isn't very fast for large arrays.

Its time complexity is

Time:  O(n²)
Space: O(1)

So I probably won't suddenly replace production sorting with Bubble Sort tomorrow. 😸

But as a learning example, I really like it.

Why?

Because you can see the algorithm working.

👀 Let's View View It

This is probably the most visually satisfying one of the three.

dsa-view-view.vercel.app

Instead of only reading

[nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];

we can follow the values moving through the array.

[5, 1, 4, 2, 8]

 ↓ swap

[1, 5, 4, 2, 8]

    ↓ swap

[1, 4, 5, 2, 8]

       ↓ swap

[1, 4, 2, 5, 8]

Then another pass begins.

The code contains nested loops, indexes, comparisons, and swaps.

But visually, the basic rule is extremely simple:

Compare neighbors. If the left one is bigger, swap them.

Repeat. Repeat. Repeat.

Sorted! 🎉

🧠 What Did We Actually Learn?

These three problems look quite different.

But each one introduces a useful way of thinking.

Two Sum

Remember information from previous steps.

Have I already seen what I need?

Binary Search

Use what we already know to remove impossible candidates.

Can I safely discard half of the search space?

Bubble Sort

Break a larger problem into many small comparisons.

Are these two values in the correct order?

This is one of the things I find interesting about learning DSA.

At first, the implementation can look like a collection of indexes, loops, conditions, and mysterious variables.

But behind the code, there is usually a much simpler idea.

And sometimes I don't fully understand that idea just by staring at the code.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at three classic algorithms:

Two Sum with a Map
Binary Search
Bubble Sort

And more importantly, we looked at how the data changes while they run.

I think this is where visualization can be especially useful.

Reading the final implementation tells us what the code is.
Stepping through it helps us understand why it works.

That's exactly why I built DSA View View.

dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try taking a problem you already solved and viewing it step by step.

You may notice something you didn't notice when only reading the code. 👀

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

And my DSA View View has launched at TinyLaunch! 🚀 Please take a loot 👇

tinylaunch.com

See you in the next article!

is-kit Reached 50 Stars ⭐ Here’s How We Use It in Production

nyaomaru — Wed, 12 Aug 2026 13:16:48 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who is trying to lose weight. 🐖🙀

I maintain a type guard library, is-kit.

I spend an unreasonable amount of time asking

“But what if this value is actually unknown???”

Recently, is-kit crossed 50 GitHub stars 🎉🎉🎉

A star is not a benchmark. And 50 stars do not suddenly make a library production-ready.

But each one still means

“Someone found this idea useful.”

That makes me very happy!! Each star gives me more motivation to keep improving the library!!!!

There is also something more concrete I want to share

is-kit is now used in a production TypeScript application serving more than 100,000 users. 🚀

This article explains:

What problem we had
How we introduced is-kit
What actually changed
Where it is used today
What its practical advantages are

Let's dive in!

📋 The Problem Was Not “Validation”

The application already had many small checks like 👇

typeof value === "string";
typeof value === "number";
value === null || value === undefined;

It also had user-defined type guards for:

HTTP client errors
Status codes
Literal unions
Arrays
Plain objects
Values coming from JSON or API responses

Each check was reasonable by itself.

The problem appeared when they started repeating.

For example, several error guards had almost the same structure.

type HttpClientError<T = unknown> = Error & {
  isHttpClientError: true;
  response?: {
    status: number;
    data: T;
  };
};

function isUnauthorizedError(error: unknown): error is HttpClientError {
  return (
    !!error &&
    (error as HttpClientError).isHttpClientError === true &&
    (error as HttpClientError).response?.status === 401
  );
}

function isValidationError(error: unknown): error is HttpClientError {
  return (
    !!error &&
    (error as HttpClientError).isHttpClientError === true &&
    (error as HttpClientError).response?.status === 422
  );
}

This works.

But it has three practical problems:

The same base check is repeated
Assertion casts appear inside every guard
Adding another status means adding another copy

The code was not broken.

It was simply asking for a reusable abstraction. 🔧

🏃‍♂️ The Production Pattern

We replaced the repeated checks with small composable guards.

Here is a business-neutral version of the production pattern.

import { define, equalsKey, or } from "is-kit";

type HttpClientError<T = unknown> = Error & {
  isHttpClientError: true;
  code?: string;
  response?: {
    status: number;
    data: T;
  };
};

const isHttpClientError = define<HttpClientError>((value) =>
  equalsKey("isHttpClientError", true)(value),
);

const isHttpErrorWithStatus = (status: number) =>
  define<HttpClientError>(
    (value) => isHttpClientError(value) && value.response?.status === status,
  );

export const isUnauthorizedError = isHttpErrorWithStatus(401);

export const isValidationError = isHttpErrorWithStatus(422);

const hasTimeoutCode = define<HttpClientError>(
  (value) => isHttpClientError(value) && value.code === "TIMEOUT",
);

const hasTimeoutMessage = define<HttpClientError>(
  (value) => isHttpClientError(value) && value.message.includes("timed out"),
);

export const isTimeoutError = or(hasTimeoutCode, hasTimeoutMessage);

There are a few important details here.

`define`

define<T> turns a runtime boolean check into a reusable predicate.

const isHttpErrorWithStatus = (status: number) =>
  define<HttpClientError>(...);

The responsibility is still ours. The runtime check must actually prove T.

is-kit cannot make an incorrect predicate correct.

But it gives custom guards one consistent shape.

`equalsKey`

The base error is not plain JSON.

It is an error instance with a marker property.

So a plain-object schema is not the right abstraction here.

equalsKey("isHttpClientError", true) expresses exactly what we need,

“This value owns this key, and its value is exactly true.”

`or`

A timeout can be detected in more than one way.

Instead of creating another large conditional, we compose two reusable guards.

const isTimeoutError = or(hasTimeoutCode, hasTimeoutMessage);

That is the core idea of is-kit,

Build small guards, then compose them.

✨ What Actually Changed

The first adoption refactor was not just 👇

pnpm add is-kit

It changed the structure of the guard layer.

Observable result	Change
Error guards	7 separate modules became 1 shared module
Adoption diff	335 lines added, 584 removed
Net diff	249 fewer lines
Direct imports today	`is-kit` is isolated to 7 app helper modules
App reach today	Those helpers are consumed by 39 non-test source files

The diff includes rewritten tests and helper adapters, so 249 fewer lines is not a claim that a library magically deletes code.

It is the measured result of that specific consolidation.

The more important change is the shape.

is-kit primitives
       ↓
app guard helpers
       ↓
features, routes, services, and UI

The production application does not import is-kit from every component.

Instead, most call sites use application-owned helpers.

🤔 Why Keep an Application Boundary?

For primitives, the application wraps or re-exports the library guards 👇

import {
  isNumber as isFiniteNumberGuard,
  isNumberPrimitive,
  isString as isStringGuard,
} from "is-kit";

export const isString = isStringGuard;
export const isNumber = isNumberPrimitive;
export const isFiniteNumber = isFiniteNumberGuard;

This looks like a small detail, but it is an important design choice.

JavaScript has more than one useful meaning for “number”.

typeof NaN === "number";
typeof Infinity === "number";

In the application:

isNumber follows primitive typeof semantics
isFiniteNumber rejects NaN and Infinity

The application owns those names. is-kit provides the reusable implementation.

This boundary also means:

Call sites do not depend on library naming decisions
Semantics stay consistent across the app
A future migration has one clear place to start

This is how I prefer to introduce small libraries into large applications.

Adopt them behind a local vocabulary.

😎 Other Real Usage Patterns

The HTTP error guards are the largest example, but not the only one.

Arrays

import { arrayOf, isNumberPrimitive } from "is-kit";

export const isNumberArray = arrayOf(isNumberPrimitive);

This replaces

const isNumberArray = (value: unknown): value is number[] =>
  Array.isArray(value) &&
  value.every((item): item is number => typeof item === "number");

Literal unions

import { oneOfValues } from "is-kit";

const VIEW_MODES = ["compact", "comfortable"] as const;

const isViewMode = oneOfValues(VIEW_MODES);

declare const input: unknown;

if (isViewMode(input)) {
  // "compact" | "comfortable"
  input;
}

Nullish values

import { isNull, isUndefined, or } from "is-kit";

export const isNullish = or(isNull, isUndefined);

Because this is a function, it can be reused directly.

const definedItems = items.filter((item) => !isNullish(item));

The current application uses the same idea for:

Error branching
JSON and API-derived values
Filtering nullable collections
Literal-value checks
UI values that may be strings or other renderable values

This is what production usage looks like in practice.

not one giant schema,
but many small decisions at normal control-flow points.

🚀 The Practical Advantages

After using it in the application, the advantages became clearer.

1. Incremental adoption

We did not need to redesign the data layer.

A check like

typeof value === "string";

can become

isString(value);

And later, if reuse becomes useful.

values.filter(isString);

2. Less assertion casting

The old error guards repeatedly used

error as HttpClientError;

The composed version narrows once, then accesses the narrowed value normally

isHttpClientError(value) && value.response?.status === status;

3. Shared runtime semantics

Questions like these now have explicit answers:

Does “number” include NaN?
Does this object check accept class instances?
Is this field optional, nullable, or both?
Are two values compared with === or Object.is semantics?

The benefit is not shorter syntax alone.

It is fewer slightly-different answers across the codebase.

4. Normal TypeScript control flow

The result is still a function.

if (isValidationError(error)) {
  error.response?.data;
}

No parse result is required.

No schema object has to travel through the application.

That makes the guards easy to use in:

if
filter
event handlers
error boundaries
utility functions

5. Small dependency surface

is-kit has no runtime dependencies.

That does not mean it has zero bundle cost.

It means introducing it does not bring a tree of transitive runtime packages with it.

👮 It Became a Team Rule

One sign of real adoption is that the library moved beyond individual preference.

The production repository now has a contributor rule:

When combining is-kit guards,
prefer or, and, andAll, nullish, and related combinators
instead of rebuilding the same composition with native operators.

For example,

const isTextOrNumber = or(isString, isNumberPrimitive);

instead of,

const isTextOrNumber = (value: unknown) =>
  isString(value) || isNumberPrimitive(value);

Both can return the same boolean.

But the first version is a named, reusable guard that can be passed around and composed again.

This rule is also used by coding agents working in the repository.

That matters because a tool is not truly adopted if every contributor, human or AI, invents a different style.

✖️ What We Cannot Claim

I want to be careful here.

We did not run a controlled study showing that is-kit:

Improved runtime performance
Reduced production incidents
Made every validation task easier

So I will not claim those things.

The effects we can actually see are:

Repeated guards were consolidated
Assertion heavy checks became composable predicates
Primitive semantics became centralized
Application code gained reusable narrowing functions
The pattern became part of the repository guidelines

This is primarily a maintainability and type-safety improvement. 🏋️‍♂️

👀 Why Not Use a Schema Library?

For these call sites, we did not need:

Rich validation error trees
Data transformations
A schema-first model

We needed

“Can this unknown value safely enter this branch?”

That is exactly where a type guard fits.

For forms, API contracts, or detailed validation errors, a schema library such as Zod may still be the better tool.

They solve different problems.

🎯 What 50 Stars Means to Me

50 stars is small compared with the largest TypeScript libraries.

But OSS does not become meaningful only after thousands of stars.

For me, this milestone means:

People outside the project understand the idea
The API is useful beyond a toy example
The library is solving a real maintenance problem
There is still a lot to improve

And the production application gives the milestone some weight.

is-kit is not only being starred.

It is currently helping real application code answer:

“What is this value, and can TypeScript trust it?”

Thank you to everyone who starred, tested, reported an issue, or simply looked at the repository.

If small composable type guards fit your TypeScript style, give it a try 👇

is-kit

Build small guards. Compose them.

is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards.

It helps you write small isFoo functions, compose them into richer runtime checks, and keep TypeScript narrowing natural inside regular control flow.

Runtime-safe 🛡️, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow.

Build and reuse typed guards
Compose guards with and, or, not, oneOf
Validate object shapes and collections
Parse or assert unknown values without a large schema framework

📚 Documentation Site · 🧭 Practical Guides

Best for app-internal narrowing, filtering, and reusable guards.

🤔 Why use `is-kit`?

Tired of rewriting the same isFoo checks again and again?

is-kit is a good fit when you want to:

write reusable isX functions instead of one-off inline checks
keep runtime validation lightweight and dependency-free
narrow values directly in if, filter…

View on GitHub

Celebrating 10,000 Total Views on DEV! 🥳 Let’s Check the Stats 😸

nyaomaru — Wed, 05 Aug 2026 13:54:19 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who recently watched a flock of geese march through Heerlen. 🪿🪿🪿

Thank you for reading my articles!

My total views on DEV have now passed 10,000! 🎉🎉🎉

I'm so happy that my articles have been read by so many developers.

To celebrate this milestone, I opened my article dashboard and checked my overall stats and post rankings.

Let's take a look together!

📊 DEV Post Stats

I have published 28 posts since 28 September 2025, excluding this one.

Here are my overall stats:

Here are the average stats per article 👇

Category	Average
Views	387.5
Reactions	24.5
Comments	3.6

I'm honestly surprised by these results!

I'll continue publishing more interesting posts. 💪

👑 Post Rankings

In this article, I'll introduce my top posts in the following categories:

Most Reactions
Most Comments
Most Views
My Personal Recommendations

💖 Most Reactions

The article with the most reactions is...

Drrrrrr... 🥁

Which OpenAPI Codegen Should You Choose? openapi-typescript vs Hey API vs Orval vs Kubb

nyaomaru

May 20

Which OpenAPI Codegen Should You Choose? openapi-typescript vs hey-api vs Orval vs Kubb

#typescript #openapi #frontend #webdev

18 min read

It received 60 reactions!! Thank you very very much. 🙏

I'm especially proud of this result because this was the article I worked hardest on.

I tested each library against a large production codebase, and we actually adopted Hey API in our system's CI pipeline.

I also recently tried generating Faker data and mocks with Hey API, and both features were excellent.

After that, I evaluated the libraries again. What interested me most was the impressive performance of Kubb v5, which is currently in beta.

In my test, Kubb v5 was more than five times faster than v4!

That is some amazing performance tuning.

We should keep an eye on how OpenAPI code generators continue to evolve.

💬 Most Comments

The article with the most comments is...

Drrrrrr... 🥁

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

It received 21 comments!! Thank you very much. 🙏

I recently released DSA View View, and this article introduces the project.

It is still brand new, so please take a look!

If you want to improve your software engineering skills, DSA View View may help you understand data structures and algorithms more clearly.

The article covers questions such as:

Why do we still need to learn DSA in the AI era?
How can you use DSA View View?
What should you study first?

You can find the answers in the article.

👀 Most Views

The article with the most views is...

Drrrrrr... 🥁

Let’s Learn Feature-Sliced Design (FSD)

nyaomaru

Sep 28 '25

Let’s Learn Feature-Sliced Design (FSD)

#architecture #design #tutorial #frontend

4 min read

It has received more than 1,900 views! Thank you very much. 🙏

Because this was my first post on DEV, simply being online longer may have helped it reach this number.

However, I also think Feature-Sliced Design can be a useful architecture for AI-assisted development.

The clear separation between layers, slices, and segments can make a codebase easier to understand and maintain.

Of course, learning FSD requires some time and effort. However, AI tools can learn this structure, and humans can follow it too.

If you are struggling to maintain a legacy codebase, FSD may be worth trying.

⭐ My Personal Recommendations

This is a special section containing some of my personal favourite articles.

One of my recommendations is...

Drrrrrr... 🥁

🧠 Understanding Variance in TypeScript & Flow: Covariant, Contravariant, Invariant, Bivariant

nyaomaru

Nov 26 '25

🧠 Understanding Variance in TypeScript & Flow: Covariant, Contravariant, Invariant, Bivariant

#typescript #javascript #react #beginners

10 min read

In this article, I tried to explain variance in TypeScript.

I often forget the differences myself, so I wrote this article as a reference—and I still go back and read it. 😸

If you are struggling to understand variance in TypeScript, please check it out!

And here is one more recommendation.

Drrrrrr... 🥁

is-kit vs Zod: A Practical Comparison from 3 Perspectives

nyaomaru

Apr 22

is-kit vs Zod: A Practical Comparison from 3 Perspectives

#typescript #opensource #programming #productivity

3 min read

What is is-kit?

If that is what you are thinking, please read the article!

is-kit is a lightweight and simple type guard kit.

If you want an easy way to protect your code from unknown values, you may enjoy using is-kit.

🎯 Summary

I'm really happy to publish this celebration article.

My next milestone is 30,000 total views!

I'll continue publishing interesting articles about frontend development, TypeScript, architecture, developer tools, and my own projects.

If any of these articles caught your attention, please take a look.

I hope at least one of them helps you!

See you in the next article!

How I Made JavaScript Execution Visual and Rewindable (DSA View View 👀👀)

nyaomaru — Wed, 29 Jul 2026 10:42:13 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who was recently knocked off my feet by how good the zeetong (sole) from a Dutch fish shop was. 🐟😸

In the previous article, I explained how DSA View View takes the TypeScript written by a user, analyzes the function or class signature, and generates a Verification form.

nyaomaru

Jul 22

How I Built the Editor and Compile Pipeline for a TypeScript DSA Visualizer (DSA View View 👀👀)

#typescript #react #webdev #opensource

10 min read

This time, we are entering the heart of DSA View View: the Runtime and Visualization layers.

If you call an ordinary JavaScript function, the direct result you get back is usually the final return value.

But when I am studying DSA, that is not the part I really want to see.

I want to know:

What happened in the middle of the loop?
When did the pointer move?
At which exact moment did the variable change?
How deep did the recursion go?

In other words, I want to see the journey to the answer, not only the answer itself.

JavaScript, unfortunately, does not provide an API that accepts:

"Excuse me, could you move the current line one step backward?"

So how does DSA View View rewind execution?

Here is the answer up front. 😸

Before execution, DSA View View rewrites the code into a version that can record its intermediate state, then runs it until it completes or reaches a configured limit.

The UI then plays those recorded states forward and backward like security-camera footage.

In this article, we will look at that record-and-replay system through:

AST transformation with Babel
Injecting recordStep calls
Preserving the original meaning of the code
ExecutionStep and snapshot patches
Rewinding and jumping to variable changes
Running code inside a Web Worker
Detecting the appropriate Visualization
Tests that protect the AST transformation

The source code is available here 👇

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

All right, let’s open the Runtime and see what Mr. View has been watching. 👀👀

📝 The Big Picture: Turning Execution into an Array of Steps

The Runtime pipeline looks roughly like this.

User TypeScript
      ↓
Prepare common DSA classes
      ↓
Parse the code into an AST with Babel Parser
      ↓
Visitors inject recordStep(...)
      ↓
Transform TypeScript into JavaScript with Babel
      ↓
Execute it with new Function inside a Web Worker
      ↓
Generate ExecutionStep[]
      ↓
React moves currentStep forward and backward
      ↓
Display the Visualization that matches the trace

The most important design decision here is that the user’s code is not connected directly to a React component.

Instead, ExecutionStep[] acts as a shared recording format.

That lets arrays, pointers, recursion, trees, heaps, and other structures all live on the same timeline.

Let’s walk through how that works.

🔭 Runtime: Planting Observation Points in the Code

This is the heart of DSA View View. 💖

The Runtime needs intermediate states, so it does not execute the user’s code exactly as written.

First, Babel transforms the AST and injects calls to recordStep.

Injecting `recordStep` into the AST

Suppose the user writes.

let left = 0;

while (left < right) {
  left++;
}

DSA View View parses it into an AST and transforms it into something roughly like this.

let left = 0;
recordStep("variable-declaration", 1, "let left = 0", { left });

while (left < right) {
  recordStep("loop-iteration", 3, "while (left < right)", { left, right });

  left++;
  recordStep("assignment", 4, "left++", { left, right });
}

The second argument to recordStep is the original source line number, not the execution-step number.
Because line 2 is empty, the recorded lines are 1, 3, and 4.

In the real implementation, dedicated visitors handle AST nodes such as:

FunctionDeclaration
FunctionExpression
ArrowFunctionExpression
ClassMethod
VariableDeclaration
AssignmentExpression
UpdateExpression
CallExpression nodes that mutate arrays
for / while / for...of / for...in
ReturnStatement

A step can therefore be recorded when:

A function is entered
A variable is declared
A loop completes an iteration
A value is assigned
An array is mutated
A function returns

Current limitation
callback bodies inside methods such as sort, reduce, map, filter, and forEach are intentionally excluded from instrumentation for now.

The goal is not to trace every corner of JavaScript immediately. I am starting with patterns that are useful for DSA traces and can be instrumented without breaking the original behavior.

Injecting the Code Is Easier Than Not Breaking It

The hardest part of the AST transformation was not calling recordStep.

The hard part was making sure that,

after adding the recording logic, every original expression is still evaluated the same number of times and still returns the same value.

For example, if a return expression were evaluated once for recording and once for the actual return, its side effects would run twice.

return someFunction();

So the transformed code first stores the value in a temporary variable.

const algorithmVisualizerReturnValue = someFunction();

recordStep("return", line, description, {
  "return value": algorithmVisualizerReturnValue,
  "return location": returnLocation,
});

return algorithmVisualizerReturnValue;

Assignment expressions are another fun little trap.

Consider this.

const result = (arr[i++] = 7);

The transformed code must preserve all three facts:

i++ runs exactly once
The pre-increment value of i is used as the array index
The assignment expression itself evaluates to 7

DSA View View wraps the assignment in a synthetic arrow function, stores the result in a temporary variable, records the step, and returns the same value.

Using an arrow function also avoids accidentally stealing the surrounding this or arguments.

AST transformation cannot be "close enough".

If adding more visible steps changes the answer, the visualizer has somehow become the least trustworthy character in the story.

Not ideal.

🖍️ `ExecutionStep`: Making Execution Replayable

The Runtime records each observed state as an ExecutionStep.

A shortened version of the real type looks like this.

type ExecutionStep = {
  stepNumber: number;
  type: ExecutionStepType;
  line: number;
  column?: number;
  description: string;
  variables: Record<string, unknown>;
  timestamp: number;
  callStack?: string[];
  scope?: string;
  metadata?: {
    loopIteration?: number;
    conditionResult?: boolean;
    functionName?: string;
    heapTrace?: HeapTraceSnapshot;
  };
};

The Runtime currently generates steps including:

function-call
function-entry
variable-declaration
assignment
array-mutation
loop-iteration
return

line and description are used in the timeline.

variables provides the data needed to reconstruct the UI at that moment.

Recursive traces also use callStack, while prepared heap implementations can attach metadata.heapTrace.

Saving References Would Rewrite the Past

Suppose an array reference were stored directly inside a step.

const stack = [0, 1];
recordStep(/* save stack */);

stack.pop();

If the recorded step keeps the same reference, the earlier state will also appear as [0] after pop() runs.

That is not a historical record.

That is the past quietly editing itself.

So values passed to recordStep are deep-cloned at that moment.

The Runtime normally uses structuredClone. When it encounters values that need different handling, it falls back to a cloning implementation that supports cycles, Map, Set, Date, RegExp, and other cases.

The "Delta Snapshot" Is Really More Like a Patch

The implementation contains a name called variableDeltas, but this deserves a more precise explanation.

The current Runtime does not compare every value with the previous state and store only the keys that truly changed.

Instead:

The first step stores the initial state, including the inputs
Later steps deep-clone the visible variables passed to that recordStep
When a full snapshot is needed, the patches are merged in order
Reconstructed snapshots are cached

So, strictly speaking, these are closer to per-step patches than minimal deltas.

Step 0 patch: { left: 0, right: 5 }
Step 1 patch: { left: 1 }
Step 2 patch: { right: 4 }

Reconstructing them produces.

Step 0 snapshot: { left: 0, right: 5 }
Step 1 snapshot: { left: 1, right: 5 }
Step 2 snapshot: { left: 1, right: 4 }

The variables property of each ExecutionStep is a getter.

It starts from a previously cached snapshot and merges only the patches needed to reach the requested step.

There is one more implementation detail worth mentioning.

The Runtime sends state from the Worker to the UI with postMessage. During that structured clone, reading the getter also materializes the snapshot.

So the data does not remain a tiny delta forever and magically arrive on the main thread in that form.

The design mainly reduces eager reconstruction and cloning while the execution is being recorded. 📽️

Why Can the Timeline Move Backward?

DSA View View is not reversing JavaScript while it runs.

Inside the Web Worker, it first rewrites the code into an instrumented version and records the execution.

During playback, the main value that changes is currentStep.

type ExecutionState = {
  currentStep: number;
  totalSteps: number;
  steps: ExecutionStep[];
  isComplete: boolean;
  returnValue?: unknown;
  error?: string;
};

Moving forward displays the snapshot for currentStep + 1.

Moving backward displays the snapshot for currentStep - 1.

So rewinding means,

selecting an earlier recorded frame, not undoing the execution itself

Once recording has finished, users can navigate without rerunning their code:

Pause
Move one step forward or backward
Jump to any step in the timeline
Move to the first or final step

Users can also select a variable and jump directly to the previous step where its value changed.

That is especially useful for pointers such as i, left, and right.

No more clicking the Back button 47 times while whispering, "Where did you go wrong?" 😸

There Is a Generator, but It Does Not Suspend the User’s Code Line by Line

The Runtime API contains a Generator<ExecutionStep, ...>.

That might make it look as if the user’s code itself is being paused line by line with yield.

It is not.

After yielding the first function-call step, the instrumented code runs once and accumulates steps inside the execution context.

The generator then yields the already-recorded steps in order.

In the path used by the UI, the Worker consumes the generator completely and returns the finished ExecutionState.

Separating execution from playback is what makes the rewind behavior relatively simple.

⚙️ Web Worker: Do Not Take the UI Down with You

User code runs inside a dedicated Web Worker instead of the main thread.

new Worker(new URL("./execution-worker.ts", import.meta.url), {
  type: "module",
  name: "algorithm-execution",
});

An infinite loop or expensive computation on the main thread would freeze the entire page.

By moving execution into a Worker:

The React UI stays on the main thread
Starting a new run or leaving the page can terminate the Worker through an AbortController

The Runtime also has limits:

Execution timeout: 10 seconds
Maximum recorded steps: 3,000

When a limit is reached, the Worker can be terminated or execution can stop early with a warning.

A Worker Is Not a Security Sandbox

A Web Worker does not have access to the page DOM, localStorage, or sessionStorage.

DSA View View also does not execute user code on a server.

However, a Web Worker is not a security boundary that makes untrusted code safe.

The user code runs through new Function in the Worker global scope.

Web APIs available inside Workers, including fetch, are not automatically disabled.

The purpose of this architecture is to:

Isolate heavy execution from the main thread
Terminate an execution unit on timeout or cancellation

It is an execution boundary for responsiveness and control, not a magical prison for JavaScript.

JavaScript has watched enough escape-room videos to know better.

👀 Visualization: Variables Alone Are Not Enough

The Runtime returns an ExecutionState and snapshots for each step.

The next problem is deciding which View should display that trace.

DSA View View does not ask AI,

"Hey, does this look like Binary Search?"

on every run.

Instead, visualization candidates are detected through logic based on:

Variable names
Variable types and data structures
Whether arrays or matrices actually changed
Pointers such as left, right, and mid
The call stack
Function-entry and return history
Heap metadata
Changes across multiple steps

For example, displaying a Sort Graph whenever a number[] exists would classify algorithms that only read an input array as sorting algorithms.

So the detection logic checks whether the numeric array actually changes between steps.

It also looks for context such as sort, swap, partition, and pivot in descriptions or the call stack.

Some representative mappings are 👇

Runtime state	Displayed View
A changing numeric array	Sort Graph
An array used as a stack	Stack View
Search using `left` / `right` / `mid`	Index View
Sliding Window pointers	Sliding Window View
A two-dimensional array	Matrix View
DP arrays or rolling state	DP View
`TreeNode`	Tree Graph
`ListNode`	List Graph
Recursive function entry and return	Recursion Tree
Logic using `Map`	Map View
Logic using both `MinHeap` and `MaxHeap`	Heap View
Word Ladder-style BFS	Word Ladder View
Container / rain-water / histogram pointers	Area View
Calculator character positions and sign stack	Expression View

When multiple candidate Views are found, DSA View View assigns priorities and selects a primary Visualization.

For example, if heap state is available, Heap View takes priority over an ordinary array View.

Visualization Is Built from `ExecutionState`

Each Visualizer knows nothing about the user’s source code.

It extracts what it needs from the current ExecutionState and converts that data into View-specific state.

<BinarySearchVisualizer
  data={data}
  indexState={{
    left,
    right,
    mid,
  }}
/>

When currentStep changes, the same Visualizer receives a new state.

CSS transitions and Framer Motion animate the difference, making pointers and nodes appear to move.

This creates a clean separation of responsibilities:

Runtime creates a correct trace while preserving the original behavior
Detection decides which View best represents the trace
Visualization focuses on how to display that state

Adding a new visualization generally follows this path:

Detect the target execution state
Convert it into View-specific state
Render it with a React component
Add it to the primary-visualization selection
Add the smallest reproducible code sample as a test

🧪 Tests: Reducing the Number of "It Happened to Work" Cases

Users can write code freely, which means they can also write it in ways I never expected.

AST transformations are especially dangerous because fixing one syntax pattern can quietly break another.

So when a real issue appears, I keep the smallest version of that code as a regression test.

Examples include:

Arguments and local variables for each recursive call
Postfix i++
XOR assignment
Nested array mutations
Class constructors and super()
TreeNode / ListNode inputs
Heap operations
Binary Search and Sliding Window pointers
Word Ladder BFS state
Worker timeouts and step limits

Trusting human memory to say,

"Surely this syntax still works."

is not a particularly strong testing strategy.

Memory is surprisingly optimistic.

And it would be a little embarrassing to build a tool for avoiding confusion in DSA, only to get lost inside the tool’s own behavior.

🎯 Summary

DSA View View is not simply turning an array into a bar chart.

At a high level, it works like this:

Write TypeScript in Monaco
Analyze the source code and signature with Babel
Inject recordStep into the AST
Execute the code inside a Web Worker
Record variable snapshots and the call stack
Replay the steps with React
Display a View matching the data structure

The most important step was converting the user’s code into an array of ExecutionSteps.

Once execution becomes a sequence of steps, the same ExecutionState can power:

Pause
Forward and backward navigation
Timeline jumps
Navigation to the previous variable change
Reconstruction of recursion trees
Data-structure visualizations

The key idea is "Do not try to reverse JavaScript itself. First, transform execution into a recordable domain model".

Then,

"Runtime focuses on producing a correct trace, while Visualization focuses on presenting that trace."

Keeping Editor, Runtime, and Visualization independent from one another has been essential to making the tool extensible. Stable models such as ExecutionStep and ExecutionState connect these layers without coupling them directly.

There are still unsupported algorithms and syntax patterns, so I would love to hear from you if:

An implementation does not run
You want another data structure visualized
You think a trace would be clearer in a different View

Issues and PRs are always welcome 👇

https://github.com/nyaomaru/dsa-view-view

Now let’s run our code and watch what it is doing inside together. 👀👀

And if you enjoy the project, I would be very happy if you left a GitHub ⭐!

How I Built the Editor and Compile Pipeline for a TypeScript DSA Visualizer (DSA View View 👀👀)

nyaomaru — Wed, 22 Jul 2026 14:06:50 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer. Thanks to my daily Duolingo streak, Dutch is finally starting to sound slightly less like one extremely long word. Progress! 🦉

In my previous article, I introduced DSA View View, a tool for visualizing data structures and algorithm execution.

Features a timeline to step backward mid-loop

nyaomaru

Jul 15

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

#showdev #typescript #dsa #react

7 min read

That article covers:

Why I decided to study DSA again
What DSA View View is
How to use it
How I plan to study with it

So if this is your first time meeting Mr. View, the previous article is a good place to start.

This time, we're opening the hood.

This is the first half of the implementation story, covering everything from the moment a user writes TypeScript to the moment DSA View View generates an input form for that implementation.

We'll mainly look at:

The overall architecture and FSD
Runtime type guards with is-kit
The Monaco Editor
Static TypeScript analysis
Compilation with Babel
Extracting function signatures from the AST
Generating the Verification form

You can find the source code here:

nyaomaru / dsa-view-view

DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free.

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, MinHeap, MaxHeap, PriorityQueue, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse…

View on GitHub

All right, let's take a look together!

📝 Designing DSA View View

DSA View View has four main responsibilities:

Editor
Compile
Runtime
Visualize

There is also a Verification step in the UI, where the user provides input values before the code is executed.

The overall flow looks like below.

Each part is already a little complicated on its own, and they interact with one another quite deeply.

I could see during the design phase that a flat project structure would eventually leave future-me wandering around the repository like a lost hiker. 🌲

So I decided to use FSD (Feature-Sliced Design).

I previously wrote about how I learned FSD here.

https://dev.to/nyaomaru/lets-learn-feature-sliced-design-fsd-15bb

A simplified version of the project structure looks like this.

src/
├── app/                # App startup and global styles
├── pages/
│   └── main/           # Main page that composes the features
├── widgets/
│   ├── editor-panel/   # UI around the editor
│   ├── control-panel/  # Compile / Verification / Runtime controls
│   └── header/
├── features/
│   ├── code-editing/   # Monaco Editor, formatting, and parsing
│   ├── compilation/    # Compile behavior
│   ├── code-execution/ # AST transforms, execution, step recording, input forms
│   ├── visualization/  # Visualization detection and views
│   └── shareable-url/
├── entities/
│   ├── code/           # Code, types, and compile results
│   ├── execution/      # ExecutionState and ExecutionStep
│   ├── data-structure/ # TreeNode, ListNode, and friends
│   └── algorithm-example/
└── shared/
    ├── ui/             # Generic components such as Button, Card, and Dialog
    └── lib/            # Guards, cloning, serializers, and other utilities

For example, features/code-execution owns the behavior of executing code.

On the other hand, ExecutionState and ExecutionStep describe domain concepts, so they live in entities/execution.

Then pages/main combines the individual features and coordinates the overall flow:

After Compile succeeds, extract the signature and move to Verification
After receiving the inputs, start the Runtime
When the Runtime step changes, highlight the corresponding line in the Editor

Each slice is consumed through a public API such as index.ts, and dependencies are allowed to flow only from higher layers to lower layers.

I also verify those dependency directions and public API boundaries with architecture tests.

Drawing those boundaries helps prevent the classic.

"I changed the Runtime. Why is the Editor broken now?"

A mystery nobody ordered.

🛡️ `is-kit`: Protecting the App from `unknown` Hell

FSD can organize dependency directions, but it cannot automatically make values entering the application safe.

In DSA View View, mysterious unknown values come flying in from many directions:

AST nodes returned by Babel Parser
Messages sent between Web Workers
JSON restored from a shareable URL
Runtime snapshots recorded from user code
Arrays, trees, graphs, and heaps being inspected as visualization candidates

TypeScript is wonderfully reliable at compile time.

But at runtime, it does not interrogate a value and ask.

"Are you really an ExecutionState, or are you just wearing its name tag?"

That is where my type guard library, is-kit, comes in.

is-kit is a small, zero-dependency library for building and composing reusable TypeScript type guards.

import {
  and,
  arrayOf,
  define,
  hasKey,
  isArray,
  isNumber,
  isObject,
  isString,
  not,
  oneOfValues,
  or,
  predicateToRefine,
  type Guard,
} from "is-kit";

const isNumericString = and(
  isString,
  predicateToRefine<string>((value) => {
    return value.trim() !== "" && Number.isFinite(Number(value));
  }),
);

const isNonArrayObject = and(isObject, not(isArray));
const isNumericValue = or(isNumber, isNumericString);
const isNumericArray = arrayOf(isNumericValue);

Small guards can be combined like LEGO bricks to create more complicated runtime checks.

For example, the code that finds class methods in an AST defines a guard.

const isMethodNodeType = oneOfValues("ClassMethod", "MethodDefinition");

const hasType = hasKey("type");

const isMethodLikeNode: Guard<MethodLikeNode> = and(
  isObject,
  define<MethodLikeNode>(
    (value) => hasType(value) && isMethodNodeType(value.type),
  ),
);

After a value passes this guard, it is narrowed from a plain unknown to MethodLikeNode.

The guard can then be passed directly to filter.

const members = classNode.body.body.filter(isMethodLikeNode);

This is extremely convenient.

Without is-kit, checks like this would have multiplied across the repository:

typeof value === "object" &&
value !== null &&
"type" in value &&
Array.isArray(...)

Eventually, slightly different versions of the same guard would appear everywhere.

Six months later, I would be asking:

"What is the difference between this isObject and that isObject?"

And congratulations—we would have built a second maze inside the first maze.

At the time of writing, shared guards are used from around 69 files under src.

If Monaco and Babel are the stars on stage, is-kit is the very serious bouncer standing at every entrance to the AST, Worker, share URL, Runtime, and Visualization layers.

Mr. Unknown is not getting in.

I also use Zod in the Verification forms, but the responsibilities are different:

is-kit: Internal narrowing, filtering, and reusable runtime guards
Zod: Input form schemas, validation messages, and user-facing errors

Instead of making one library solve every problem, is-kit handles internal runtime safety while Zod handles user input validation.

I am very glad I built is-kit before building this application. Fighting all those unknown values with my bare hands would have made me the first thing that needed visualizing.

✏️ Editor

The Editor uses Monaco Editor.

Monaco is the browser-focused editor component also used by VS Code, giving the application syntax highlighting, completion, and TypeScript diagnostics.

The downside is that Monaco is not exactly tiny.

Loading everything immediately made the initial display heavier, so DSA View View first renders a lightweight textarea.

The same textarea is also used as the <Suspense> fallback, preventing the editor area from becoming empty while Monaco is loading.

<textarea
  aria-label="Code Editor"
  value={value}
  onChange={(event) => onChange(event.target.value)}
  onFocus={onActivate}
/>

Behind the scenes, DSA View View waits briefly and prepares Monaco with requestIdleCallback.

If the browser does not support requestIdleCallback, loading starts normally. If the user focuses the textarea before that, Monaco preparation begins immediately.

const CodeEditor = lazy(() =>
  prepareCodeEditorModule().then((module) => ({
    default: module.CodeEditor,
  })),
);

Once loading finishes, the lightweight editor is replaced by Monaco while preserving the same source code.

It looks like an editor, but secretly it is still a textarea.

A tiny editor body-double strategy.

Static `TypeScript` Analysis

Static analysis uses the TypeScript Worker included with Monaco.

The TypeScript Language Service runs in a separate Worker from the editor itself and returns type and syntax problems as markers.

Those markers are converted into the application's CompilationError model and used to control the Compile button and display errors.

type CompilationError = {
  line: number;
  column: number;
  message: string;
  severity: "error" | "warning";
};

The Compile button is disabled only when an error exists. Warnings alone do not prevent compilation.

One important detail is that Babel does not perform TypeScript type checking.

The responsibilities are:

Monaco's TypeScript Worker: Diagnose types and syntax
Babel: Transform TypeScript syntax into JavaScript

Keeping that distinction clear saved me from blaming Babel for crimes it did not commit.

Registering DSA Classes in the Editor

Many LeetCode problems provide classes such as TreeNode and ListNode automatically.

DSA View View also provides common classes so users do not have to declare them every time:

TreeNode
ListNode
GraphNode / _Node
TrieNode
PriorityQueue
MinHeap / MaxHeap
Deque
UnionFind / DSU
Counter

Monaco provides a mechanism called setExtraLibs, which lets the application add these type definitions to the Editor:

monaco.typescript.typescriptDefaults.setExtraLibs([
  {
    content,
    filePath: "ts:algorithm-visualizer-prepared-classes.ts",
  },
]);

However, setExtraLibs only supports type analysis inside the Editor. It does not magically create those classes at Runtime.

So the Compile and Runtime pipelines also prepend the same class definitions to the user's code as a prelude.

If the user declares a class, interface, or type with the same name, DSA View View skips injecting the prepared definition.

Imagine carefully writing your own ListNode, only for another ListNode to emerge from behind it.

That is not type safety. That is a summer horror movie.

Formatting

Formatting uses Prettier.

The Prettier core, TypeScript plugin, and Estree plugin are dynamically imported only when needed and registered as Monaco's Document Formatting Provider.

Users can therefore format their code with Command/Ctrl + S or Shift + Alt + F.

📌 From the Compile Button to Verification

So far, I have described "Compile" as if it were one large operation.

Internally, however, the FSD slice features/compilation does not own the whole flow.

When the user presses the Compile button, pages/main coordinates these operations:

features/compilation checks whether the TypeScript can be transformed into JavaScript
The parser in features/code-editing extracts the function or class signature
If everything succeeds, the UI moves to Verification
features/code-execution displays an input form matching that signature

To the user, this feels like one continuous Compile step.

Inside the application, each responsibility remains separate.

Transforming `TypeScript` with Babel

The application uses Babel to transform TypeScript.

const prepared = prepareTypeScriptCodeWithClasses(code);

const result = transform(prepared.code, {
  presets: ["typescript"],
  filename: "input.ts",
});

DSA View View runs entirely in the browser, so it is not invoking tsc on a Node.js server.

Instead, it uses @babel/standalone to transform TypeScript syntax into JavaScript in the browser.

Before transformation, the application prepends any prepared classes that the user has not declared themselves.

If the source contains imports for those prepared classes, they are removed because the browser execution environment cannot resolve those modules.

Again, an important reminder:

Babel's TypeScript preset primarily removes type information. It does not type-check the program.

Monaco handles type errors. Babel checks whether the syntax can be transformed.

The generated JavaScript from this stage is also not executed directly on the main thread.

For the Runtime, the original source is instrumented separately and then executed inside a Web Worker.

That is the fun part—and the topic of the next article.

Extracting Function Signatures from the AST

After Compile succeeds, DSA View View needs to build an input form.

Suppose the user writes this function:

function trap(height: number[]): number {
  // ...
}

The source code is parsed into an AST with Babel Parser, and DSA View View extracts information like this:

{
  name: "trap",
  parameters: [
    {
      name: "height",
      type: "number-array",
      optional: false,
    },
  ],
  returnType: "number",
}

The parser supports more than ordinary function declarations:

Function declarations
Arrow functions assigned to variables
Function expressions assigned to variables
LeetCode-style factory functions that return another function
Class declarations

For a class, the parser extracts the constructor and callable methods. private methods are currently excluded.

For class-design problems such as LRUCache and MedianFinder, it extracts the class name, constructor, method names, and arguments.

When the source contains multiple helper classes, DSA View View avoids prioritizing prepared classes as solution candidates and compares the number of callable methods to select the likely design class.

This selection is heuristic, so it cannot perfectly identify every possible class structure yet.

There are always more creative ways to write JavaScript than I expect. JavaScript considers this a feature.

Generating the Verification Form

For ordinary functions, the input form is built from the extracted signature using React Hook Form and Zod.

Supported input types include:

number
string
boolean
number[] / string[] / boolean[]
number[][] / string[][] / boolean[][]
TreeNode
ListNode
GraphNode / _Node

The input UI and validation behavior change depending on the type.

For example, a number[] accepts both:

1, 2, 3

and:

[1, 2, 3]

Both formats are converted into a real array that can be passed to the Runtime.

For TreeNode, the application constructs a tree from a level-order array.

When a problem has multiple TreeNode parameters, users can also select a specific node from the first root.

For ListNode, users can build a linked list from an array or node-based input and specify the cycle position.

For GraphNode, a cyclic graph structure is constructed from a LeetCode-style adjacency list.

Class-design problems use a different UI.

Instead of the normal parameter form powered by React Hook Form and Zod, DSA View View displays the same Operations and Arguments JSON format used by LeetCode.

For example, MedianFinder uses:

Operations: ["MedianFinder", "addNum", "addNum", "findMedian"]
Arguments:  [[], [1], [2], []]

This form validates class-design-specific requirements, including:

The number of operations matches the number of argument lists
The first operation matches the class name

So the Compile button starts a chain of separate responsibilities:

Babel verifies that transformation is possible
AST analysis extracts the signature
The Verification layer generates the appropriate input form
pages/main connects the entire flow from the Editor to Verification

🎯 Summary

In this article, we followed the path from writing TypeScript in DSA View View to generating the inputs needed for execution.

The broad flow is:

Render a lightweight textarea first
Prepare Monaco Editor in the background
Diagnose types and syntax with the TypeScript Worker
Use Babel to check whether the TypeScript can be transformed into JavaScript
Extract the function or class signature from the AST
Generate a Verification form based on the detected types

The important design decision was not forcing the Editor, diagnostics, syntax transformation, and input UI into one giant operation.

Instead:

is-kit safely narrows unknown values from the AST, Workers, JSON, and runtime snapshots
Monaco's TypeScript Worker diagnoses types and syntax
Babel transforms TypeScript syntax into JavaScript
AST analysis extracts the signature needed by the Verification UI
The Verification form validates inputs and converts them into Runtime values
pages/main connects the separate steps and advances the UI

Keeping those responsibilities separate made the flow much easier to understand and extend.

In the next article, we will finally enter the heart of DSA View View: the Runtime.

That is where Mr. View stops politely waiting beside the Editor and starts watching every move your variables make. 👀

There are still unsupported patterns and types, so Issues and PRs are always welcome!

And if you enjoy the project, I would be very happy if you left a GitHub ⭐!

https://github.com/nyaomaru/dsa-view-view

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

nyaomaru — Wed, 15 Jul 2026 12:04:25 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer currently fighting the intense European heatwave by building DIY window screens here in the Netherlands. 🛠️

https://medium.com/data-science-collective/should-you-still-learn-to-code-in-2026-034685e17707

As this article also discusses, I believe that improving our fundamental engineering skills is still essential in the age of AI.

Imagine that AI makes an F1 car fully autonomous. 🏎️

Would you let someone without even a driver’s license enter a race as its driver?

Or imagine that AI completely automates maintenance during pit stops.

Would you put someone who knows absolutely nothing about cars, their parts, or their internal structure in charge of that AI?

AI is certainly reducing the amount of code we need to write by hand. Typing quickly and memorizing every small piece of syntax or every method are becoming less important.

But can we confidently release a product without understanding its fundamental concepts or implementation? If something goes wrong in production, can we take responsibility and fix it?

My answer was no.

Building things faster is obviously a good thing. But if we build without understanding, we may simply produce fragile software with no long-term sustainability at a faster rate.

The real value comes from building meaningful things quickly.

Then, how can we develop the fundamental skills we still need in the AI era?

I believe one useful approach is learning DSA: Data Structures and Algorithms. So I decided to start learning DSA again.

However, while solving problems on LeetCode, I repeatedly ran into the same problem.

I want to visualize the data flow and understand what is happening, but I still can’t clearly see it.

So I used the skills I have developed through frontend engineering and built a tool that visualizes the execution flow of DSA implementations! 🚀

nyaomaru / dsa-view-view

DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free.

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, nested arrays, matrices, strings, numbers, and class style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse by category, and jump into…

View on GitHub

In this article, I’ll explain how DSA View View works and how we can use it to study DSA.

Let’s take a look together!

Disclaimer
I may sound confident so far, but I’m definitely not a DSA expert. I’m still learning, just like many of you.

In fact, I built this tool precisely because I was struggling. When I realized that I couldn’t immediately solve Binary Search, I started to panic a little. 😸

🖥️ What Is DSA View View?

DSA View View is a tool that executes functions and classes written in TypeScript and lets you inspect how variables and return values change on each line through a runtime timeline.

The easiest way to understand is to try it yourself!

Open the tool and click the Run Demo button.

You’ll quickly see how the workflow works:

Write your implementation
Compile it
Enter the input values
Run it

That’s really it.

Although I created it primarily for DSA problems, you can also use it to inspect and test smaller TypeScript implementations.

And, of course, it’s completely free!

🤔 What Can It Do?

With DSA View View, you can:

Write DSA implementations in TypeScript
Test implementations with different input values
Move forward and backward through runtime steps
Visualize supported data structures and algorithms
Review LeetCode solutions and confirm your understanding

You can also use it as a lightweight environment for executing functions or formatting code blocks for technical articles such as Dev.to 😸

Feel free to experiment with it and find your own use cases!

🧑‍🏫 How to Use It

The main workflow consists of three modes:

Editor
Verification
Runtime

Let’s look at each one.

Editor

First, write your implementation!

The Editor is designed to feel similar to a basic IDE.

TypeScript diagnostics are available by default, so the editor can detect some errors while you write.

You can also press Cmd/Ctrl + S to format your code with Prettier, so feel free to write first and clean it up afterward.

Common classes used in DSA problems, such as TreeNode and ListNode, are already available.

You don’t need to declare or import them every time.

You can also define your own classes or replace the provided definitions when necessary.

Once your implementation is ready, click Compile Code.

If compilation fails, the tool displays the relevant location and error message so that you can fix it.

There is also an Example menu containing several common implementations.

For example, if you want to quickly inspect a Heap Sort implementation and see how it behaves, you can load the example instead of writing everything manually.

Verification

In Verification mode, you define the input values that should be passed to your function or class.

Enter a test value for each argument.

For arrays, both of the following formats are supported:

[1, 2, 3]

1, 2, 3

Once your input values are ready, click Run.

Runtime

Finally, let’s inspect the runtime!

When you click Run in Verification mode, your implementation is executed.

Runtime mode then lets you play through the execution steps or move backward and forward manually.

When the tool recognizes supported logic, an additional visualization is displayed in a modal.

Not every possible implementation is supported yet, of course. If something you need is missing, I would be happy to receive an issue or pull request!

You can move backward and forward through the executed lines to inspect:

Which line is currently running
How variables change
Where values are returned
How the execution reaches its final result

You can return to the beginning, jump directly to the end, or move through the timeline one step at a time.

The main execution process runs entirely in the browser.

Share 🐈

DSA View View also includes a sharing feature.

You can create a URL that preserves your implementation and share it with someone else.

Use the Share button at the top of the page to post it on social media or copy the link directly.

Share your implementations, compare different solutions, and let’s learn together!

Important: The shared URL contains your implementation. Do not paste private, confidential, or proprietary code into the tool before sharing it.

What Is That Thing in the Top-Right Corner? 👀👀

Meet Mr. View.

Mr. View watches over your implementation.

Nothing more.

Nothing less.

He is simply there to support you.

When you need to concentrate, press the TV button to hide him. Press it again to bring him back.

However, if Mr. View is enough to distract you, you may not be ready for an attack from ten simultaneous Slack notifications. 😸

✏️ How Should We Study DSA?

Now you know how to use DSA View View.

The next question is probably

Which problems should I solve?

LeetCode is an obvious place to start, and the study plan from Tech Interview Handbook also provides a useful collection of practice problems. 👇

https://www.techinterviewhandbook.org/coding-interview-study-plan/

Try solving these problems with DSA View View.

Once your implementation works, use the runtime timeline to inspect the data flow and understand exactly how the algorithm reaches its answer.

You can also use tools such as ChatGPT, Codex, Claude, Claude Code, Gemini, and Grok to explore your solution further.

Don’t limit yourself to asking

Is this implementation correct?

Try asking questions such as:

What would happen if I rewrote this DFS solution using BFS?
Could Dynamic Programming solve this problem?
Are there any other reasonable approaches?
What are the time and space complexities?
Why is this approach better than the alternatives?
Under which conditions would another approach be better?

AI becomes much more useful for learning when it helps us compare and understand different approaches instead of only generating a final answer. 👍

Why TypeScript Instead of Python? 🐍

The simple answer is that TypeScript is my favorite language.

I mainly work as a frontend engineer, so TypeScript is also the language in which I feel most comfortable experimenting and learning.

However, I designed the tool so that additional languages could be supported in the future.

If there is enough demand for another language, please leave a comment or open an issue!

🎯 Conclusion

AI is helping us write code faster and faster.

However, understanding what happens inside an implementation remains an important engineering skill.

In fact, I believe that this ability may become even more valuable as AI-generated code becomes increasingly common.

I built DSA View View because I wanted a tool that could help me strengthen those fundamental skills from the ground up.

To be honest, I still have a lot to learn about DSA.

That is exactly why I hope we can learn together.

Please leave a comment or open an issue if:

You want support for a particular problem or data structure
You have an idea for a new visualization
You find a bug
You want support for another programming language

Let’s train our DSA muscles together! 💪😸

If you like it, please give a star ⭐

nyaomaru / dsa-view-view

DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free.

DSA View View

DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀

Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes.

It is built for those moments when reading the code is not enough and you want to view why the answer changes.

Why Try It?

🧠 Step through real TypeScript
Paste or edit a function, validate it, then run the exact code in the browser.
🧩 Views that match the data
Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view.
🌳 DSA-friendly inputs out of the box
TreeNode, ListNode, nested arrays, matrices, strings, numbers, and class style inputs are supported without ceremony.
🔎 39 built-in examples
Search by name, browse by category, and jump into…

View on GitHub

And I also launched on ProductHunt! Come say hello and let me know what you think 😸 👇

producthunt.com

Trying Declarative Partial Updates: A Future API for Replacing HTML Later

nyaomaru — Wed, 01 Jul 2026 12:42:05 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who was cheering for the World Cup during tropical nights in the Netherlands while nearly melting from heat exhaustion. 🫠⚽ (But yesterday was comfortable 😺)

How do you usually build frontend applications?

Do you build SPAs with React / Vue / Svelte?

Do you use SSR / SSG / ISR frameworks like Next / Remix / Nuxt / Astro?

There are many ways to build frontend applications, but today it is very common to update the DOM on the client side using JavaScript.

Even when using UI libraries and frameworks like React / Vue / Svelte, or SSR frameworks like Next / Remix / Nuxt / Astro, there are still many cases where part of the screen is eventually updated by client-side JavaScript.

But is that really always the best answer?

Are there cases where we are forcing JavaScript on the client to handle work that could naturally be handled on the server?

In response to that kind of question, the Chrome team introduced an experimental API called DPU, or Declarative Partial Updates. 🚀

Declarative partial updates | Blog | Chrome for Developers

Learn about new out-of-order streaming capabilities and the renewed HTML insertion and streaming methods available for testing from Chrome 148

developer.chrome.com

In this article, I want to explore what Declarative Partial Updates are, what problems they try to solve, and why they might matter.

I will focus especially on the out-of-order streaming mechanism that can replace parts of HTML later without writing client-side JavaScript for the replacement itself.

Let's dive in!

🧩 What are Declarative Partial Updates?

Declarative Partial Updates are, roughly speaking

A mechanism where you declare part of your HTML as “this area will be replaced later”, and then update only that part with HTML that arrives later.

For example, imagine you want to return the overall page HTML immediately, but some data is slower to fetch.

The header is instant
The layout is fast
The user profile is also pretty fast
But only the recommendations API is slow

In that case, we often show a loading state on the client, fetch data, and update the DOM with JavaScript. In React, you might reach for something like <Suspense>.

With DPU, the server can first return HTML like this.

<section>
  <h2>Recommendations</h2>

  <?start name="recommendations">
    <p>Loading recommendations...</p>
  <?end>
</section>

The area surrounded by <?start name="recommendations"> and <?end> is a region that can be replaced later.

Then, when the recommendations HTML is ready on the server, it can stream HTML like this later.

<template for="recommendations">
  <ul>
    <li>Advanced CSS Layouts</li>
    <li>Modern HTML APIs</li>
    <li>Web Performance Basics</li>
  </ul>
</template>

At that point, the browser finds the region named recommendations and replaces the loading UI with the contents of this <template>.

Wait, does that feel a bit weird?

Exactly. The wild part is that up to this point, we did not write any JavaScript for the replacement, and no framework is involved.

In other words, you no longer need to write client-side JavaScript like this just to replace that area:

const element = document.querySelector("#recommendations");
element.innerHTML = html;

You stream HTML, and the browser understands where that HTML should go.

That is the interesting part of Declarative Partial Updates.

DPU also has <?marker>, not only <?start> / <?end>.

<?marker> is basically a marker that says, “insert later HTML here.”

<div>
  <?marker name="placeholder">
</div>

<template for="placeholder">
  <p>Here is streamed content!</p>
</template>

In this case, the browser finds the marker named placeholder and inserts the contents of the later <template for="placeholder"> at that position.

On the other hand, the <?start> / <?end> pair used mainly in this article is for showing placeholder content, such as a loading UI, and replacing that entire range later.

So, roughly

<?marker> means “insert here”
<?start> / <?end> means “replace this range”

That mental model should be enough to start.

Note

<?marker> can also be used by leaving the same marker inside streamed content, which lets you append list items one by one. That is pretty interesting too.

In the first half of this article, I focus mainly on replacing loading UI, so I mostly use <?start> / <?end>.

In the later sample, I also try an example that uses <?marker> to append asset links sequentially.

🤔 Why do we need Declarative Partial Updates?

At this point, you might think

Wait, frameworks like React or Astro can already do this, right?

Yes. They can.

With React / Vue / Svelte / Next / Remix / Nuxt / Astro, you can show loading states, receive API results, and update parts of the screen. Many of us do this every day.

But wait a second. A lot of that is implemented by client-side JavaScript updating the DOM, right?

A common flow looks like this:

The server returns HTML
The browser displays the HTML
Client-side JavaScript is loaded
JavaScript calls an API
The API result is put into state
The framework updates the DOM

Of course, this is an extremely common frontend architecture today.

But if part of the screen is “something the server can already produce as HTML”, do we really need to make client-side JavaScript do that work every time?

For example, the recommendations HTML can be generated on the server like this:

<ul>
  <li>Advanced CSS Layouts</li>
  <li>Modern HTML APIs</li>
  <li>Web Performance Basics</li>
</ul>

If all we want to do is send that to the browser, it can feel a bit indirect to do this.

fetch("/api/recommendations")
  .then((res) => res.json())
  .then((items) => {
    setRecommendations(items);
  });

You fetch JSON, convert it to HTML on the client, update state, and then update the DOM.

That is convenient, but it is also a bit roundabout.

What makes DPU interesting is that it points in another direction

If the server can produce HTML, why not stream that HTML directly and let the browser insert it into the right place?

So DPU is not a replacement for React / Vue / Svelte. It is more like a lower-level browser primitive.

It may allow the browser to understand, as part of HTML itself, some of the partial update work that frameworks currently handle.

If that happens, the boundary between client-side responsibility and server-side responsibility becomes even more important.

What can be done with HTML?
What should be done with JavaScript?

By redesigning these boundaries and declaring things in a way that fits the browser, we may be able to unlock browser capabilities that we are not fully using yet.

But we should not misunderstand the client still has responsibilities.

This discussion is not about replacing state management, and interactive features still need JavaScript.

For example, forms, modals, charts, and similar UI should still be managed on the client side, while static text or server-generated HTML based on slower API responses may be a better fit for HTML streaming.

The responsibility split becomes more complex, but the UX may improve a lot. This is definitely something worth watching.

🏠 This may expand what SPAs can do

DPU is not about rejecting SPAs.

Personally, I see it as something that may expand the possibilities of SPAs.

Until now, SPAs have often followed this mental model.

Fetch data as JSON
    ↓
Put it into client-side state
    ↓
Re-render components
    ↓
Update the DOM

But if DPU and the new HTML insertion / streaming APIs become available, another option appears.

The server returns HTML
    ↓
HTML is streamed
    ↓
The browser inserts it into the existing DOM

That means an SPA could potentially choose different update strategies for different parts of the UI:

Fetch JSON and render on the client
Generate HTML on the server and insert it directly
Return only the shell initially, then stream slower parts later
Perform page-transition-like updates with HTML partials

That is really interesting.

SPAs often carry the image of “doing everything with client-side JavaScript”, but they may become more hybrid in the future. The meaning of the word SPA itself may change.

State that belongs on the client stays on the client
HTML that can be produced on the server is produced on the server

And the browser does not merely display that HTML. It also understands where and how to insert it.

If this direction continues, frontend architecture may become even more flexible and deeper than it is today.

🧪 APIs for streaming HTML from JavaScript are also coming

The interesting part of DPU is not only out-of-order streaming with <template for="...">.

The Chrome team is also proposing a new set of APIs for inserting and streaming HTML from JavaScript.

Even today, there are several ways to dynamically insert HTML.

element.innerHTML = html;
element.outerHTML = html;
element.insertAdjacentHTML("beforeend", html);

But they all have slightly different behavior.

For example:

Does it overwrite existing content?
Does it append after the existing content?
Are <script> tags executed?
What happens with sanitization?
How does it interact with Trusted Types?

There are a lot of subtle differences.

Honestly, I do not think many developers can confidently explain all of those differences from memory. I definitely cannot.

The new APIs try to make HTML insertion easier to understand with more consistent names.

For example, static HTML insertion looks like this.

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector("#content-to-update");

contentElement.setHTML(newHTML);

This is not an API that appends to the end, like insertAdjacentHTML("beforeend", html). It replaces the existing contents of contentElement with newHTML.

A useful way to understand the difference is

setHTML() is the safer API that runs through a sanitizer
setHTMLUnsafe() disables the sanitizer by default and lets you handle HTML more directly

Then comes the really interesting part of streaming versions.

const contentElement = document.querySelector("#content-to-update");

const response = await fetch("/api/content.html");

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

This is pretty wild.

It means we may be able to take HTML returned by fetch() and stream it directly into an element without waiting for the entire response to finish downloading.

SPAs have not benefited much from HTML streaming after the initial document load.

The initial document can be streamed from the server, but later screen updates often become JSON fetch + client render.

With APIs like this, SPA updates may also be able to benefit from HTML streaming.

That is why I think this may expand the possibilities of SPAs.

⚠️ “unsafe” does not mean “never use it”

When you see a name like streamHTMLUnsafe(), you might think

Unsafe!? That sounds terrifying.

I thought that too at first.

But this unsafe does not mean “you must never use it.” It is closer to a warning that the sanitizer is disabled by default, so you need to think carefully about whether the input is trusted.

For example, it would be dangerous to stream user-generated HTML directly into the DOM.

But if the HTML is generated by your own trusted server, there may be valid use cases.

Of course, before using this in production, you need to think carefully about sanitizers, Trusted Types, script execution, browser support, and other security concerns.

➕ What happens when DPU and the streaming APIs are combined?

This is the most interesting part.

DPU’s <template for="..."> and the new HTML streaming APIs are separate APIs.

But combining them makes the story even deeper.

For example, imagine placing placeholders in an SPA screen.

<main>
  <?start name="page-title">
    <h1>Loading...</h1>
  <?end>

  <?start name="page-content">
    <p>Loading content...</p>
  <?end>
</main>

Then, during a page update, the server streams HTML.

<template for="page-title">
  <h1>Dashboard</h1>
</template>

<template for="page-content">
  <section>
    <p>This is the dashboard content.</p>
  </section>
</template>

Instead of manually targeting the DOM with JavaScript.

document.querySelector("#page-title").innerHTML = titleHTML;
document.querySelector("#page-content").innerHTML = contentHTML;

the browser may be able to understand where page-title and page-content should be applied.

In other words, even in SPA-style page transitions, something like this may become possible.

Fetch a new page's HTML partial
    ↓
Stream the HTML
    ↓
Update only the necessary places via template for

Part of the work that frameworks currently handle with Virtual DOM, compilers, or fine-grained reactivity may be shifted to browser-native HTML streaming / partial updates.

That makes DPU feel like more than just a small HTML API. It feels like something that could expand the design space of frontend architecture.

Of course, this is still experimental. This is not a “let's all use this in production right now” kind of API.

But the old assumption

An SPA fetches JSON and renders on the client

may start to change.

HTML may evolve from “a static document loaded once at the beginning” into “a UI unit that can be streamed, replaced, and updated.”

That is pretty exciting, right?

🚀 Trying it with Node.js DPU samples

So far, we have talked about the concept. I also built a small Node.js sample app to try this out.

nyaomaru / declarative-partial-updates-sample

Sample repository for DPU (Declarative Partial Updates)

Declarative Partial Updates sample

A small Node.js sample app for trying Chrome's experimental Declarative Partial Updates (DPU) feature.

Images under public/ are served through the Node.js stream handler at /public/... then inserted from later DPU or HTML streaming chunks.

Styles live in public/styles.css. Shared timing and image constants live in features/shared.mjs, while public asset metadata and GitHub links live in features/public-assets.mjs so the sample behavior is easier to inspect and adjust.

The server is split by feature:

features/home/: DPU document streaming sample HTML and stream chunks
features/hybrid-shell/: hybrid shell HTML and route partial HTML
features/set-apis/: static and streaming HTML insertion sample HTML
features/public-assets.mjs: public asset metadata and stream handler
features/layout/: shared document layout HTML
features/layout.mjs: layout template renderer
features/shared.mjs: common helpers and demo timing constants
public/html-stream.js: client-side static / streaming HTML insertion helper

Run

npm start

Open:

http://localhost:3000/…

View on GitHub

Note

This is an experimental feature, so you need Chrome Canary (Chrome v148 or later) or a Chrome build that includes this feature, with the experimental flag enabled.

Open the following URL in Chrome’s address bar:

chrome://flags/#enable-experimental-web-platform-features

Enable it, click “Relaunch”, and then run the sample. This article assumes a supported build with this flag enabled.

The demo app has roughly three pages:

/              ... Document streaming
/hybrid-shell  ... Hybrid shell + streamed HTML route updates
/set-apis      ... Static / Streaming HTML APIs

The first page, /, demonstrates DPU out-of-order streaming.

The server first returns an HTML shell, and slower server-rendered fragments are streamed later as <template for="...">.

For example, the initial HTML contains a placeholder.

<article class="panel">
  <h2>Recommendations</h2>

  <?start name="recommendations">
    <p class="loading">Waiting for recommendations...</p>
  <?end>
</article>

At this point, the browser shows the loading UI.

Then, once the recommendations HTML is ready on the server, it streams a chunk.

<template for="recommendations">
  <ul class="list">
    <li>Advanced CSS Layouts</li>
    <li>Modern HTML APIs</li>
    <li>Web Performance Basics</li>
  </ul>
</template>

The browser finds the DPU range named recommendations and replaces the loading UI with the list.

On this page, I stream multiple named regions at different timings, not only recommendations:

hero image
metric
asset strip
team activity
streamed code block

The asset strip also uses <?marker>. The initial HTML has a marker.

<section class="panel asset-panel">
  <h2>Streamed public assets</h2>
  <div class="asset-grid">
    <?marker name="asset-list">
  </div>
</section>

Then the server streams chunks one by one whenever each asset link becomes ready.

<template for="asset-list">
  <!-- streamed asset link -->
  <?marker name="asset-list">
</template>

By leaving the same marker again inside the streamed content, the next asset link can continue to be appended in the same place.

So HTML does not have to wait until everything is complete from top to bottom. Fragments can be streamed in later as soon as they are ready.

That is the really interesting part of DPU.

Note

<template for> has several subtle rules, including constraints related to parent elements.

This demo is a sample for exploring the direction of the API, but if you want to use it in production someday, you should carefully check the applicable range of <template for>, DOM movement during streaming, Trusted Types, sanitizers, and related details.

🌓 Trying a hybrid shell style architecture

Next, /hybrid-shell demonstrates streaming HTML route updates inside a hybrid shell style architecture.

This is not a “pure SPA where everything is rendered on the client”. It is closer to an architecture where the whole document is not reloaded, the URL changes through the History API, and only the route content inside the shell is updated.

The goal is

Keep client-side state alive, while replacing only the route content with server-generated HTML.

For example, this page has a counter:

<div>
  Counter: <strong id="counter">0</strong>
  <button id="increment" class="primary" type="button">Increment</button>
</div>

This counter is managed by client-side JavaScript.

document.querySelector("#increment").addEventListener("click", () => {
  counter.textContent = String(Number(counter.textContent) + 1);
});

So this is clearly a client-side responsibility.

On the other hand, route content is fetched from the server as HTML.

const loadRoute = async (route, { push = false } = {}) => {
  setActiveRoute(route);

  if (push) {
    const nextUrl =
      route === "dashboard"
        ? "/hybrid-shell/dashboard"
        : `/hybrid-shell/${route}`;
    window.history.pushState({ route }, "", nextUrl);
  }

  const response = await fetch(`/partials/hybrid-shell/${route}`);
  view.replaceChildren();

  if ("streamHTMLUnsafe" in Element.prototype && response.body) {
    await response.body
      .pipeThrough(new TextDecoderStream())
      .pipeTo(view.streamHTMLUnsafe());
    return;
  }

  const template = document.createElement("template");
  template.innerHTML = await response.text();
  view.replaceChildren(template.content.cloneNode(true));
};

What this does is not “fetch JSON and render components on the client.” Instead, it streams HTML generated by the server directly into the view.

The counter state remains on the client.

That means we can split responsibilities:

Interactive state such as the counter belongs to the client
Server-generated route body can be streamed as HTML

This feels close to the thinking behind island architecture in frameworks like Astro / Fresh.

Instead of making the client do everything, we separate HTML that can be returned statically or from the server from interactive client state.

Personally, I find this very interesting.

At the very least, a shell with SPA-like navigation does not have to mean “everything is rendered by client-side JavaScript.” It may also expand into a hybrid shape that combines client state with streamed HTML.

Note

This /hybrid-shell sample is not a demo that replaces a range inside the shell using DPU’s <?start> / <template for>.

The Chrome team article also introduces the possibility of SPA-style page loads by combining streamHTMLUnsafe() and <template for>.

However, in my local tests, I could not confirm that streaming <template for="..."> into streamHTMLUnsafe() in this shell architecture updates an existing DPU range.

The SPA-style page load described in the official article seems to point toward an outline page with processing instructions, where the new page’s <template for> elements are streamed toward the end of the HTML and slotted into those instructions.

So in this /hybrid-shell sample, I do not handle DPU range replacement. Instead, I use the HTML streaming insertion API to stream server-generated route partials directly into #hybrid-shell-view.

🎁 Trying Static / Streaming HTML APIs

Finally, /set-apis tries the new HTML insertion / streaming APIs separately from DPU’s out-of-order streaming.

This page first checks whether the browser has the APIs.

support.innerHTML = `
  <ul class="list">
    <li>setHTMLUnsafe: ${"setHTMLUnsafe" in Element.prototype}</li>
    <li>streamHTMLUnsafe: ${"streamHTMLUnsafe" in Element.prototype}</li>
  </ul>
`;

For static insertion, if setHTMLUnsafe() is available, the demo uses it. Otherwise, it falls back to <template> and replaceChildren().

if ("setHTMLUnsafe" in Element.prototype) {
  staticTarget.setHTMLUnsafe(markup);
  return;
}

const template = document.createElement("template");
template.innerHTML = markup;
staticTarget.replaceChildren(template.content.cloneNode(true));

For streaming insertion, it pipes the fetched HTML response directly into streamHTMLUnsafe():

const response = await fetch("/partials/set-apis/stream");

streamTarget.replaceChildren();

if ("streamHTMLUnsafe" in Element.prototype && response.body) {
  await response.body
    .pipeThrough(new TextDecoderStream())
    .pipeTo(streamTarget.streamHTMLUnsafe());
  return;
}

If this works, we can stream chunks into an existing element as they arrive, instead of waiting until the entire HTML response has downloaded and inserting it all at once.

Traditionally, SPAs could benefit from HTML streaming for the initial document, but subsequent screen updates often became JSON fetch + client render.

With APIs like this, SPAs may be able to benefit from HTML streaming even for later updates.

That is the exciting part of DPU and the new HTML streaming APIs.

The static insertion partial is returned from /partials/set-apis/static, and the streaming insertion partial is returned from /partials/set-apis/stream.

🎯 Summary

In this article, I looked at Declarative Partial Updates introduced by the Chrome team.

Declarative Partial Updates are, roughly

A mechanism where you declare part of your HTML as “this area will be replaced later”, and then update only that part with HTML that arrives later.

Of course, DPU does not replace React / Vue / Svelte / Next / Remix / Nuxt / Astro.

Interactive UI, client-side state management, forms, modals, charts, drag and drop, and similar features still need JavaScript.

But on the other hand, there may be more cases where we do not need to handle everything with client-side JavaScript.

HTML that can be generated on the server should be generated on the server
State that should be managed on the client should be managed on the client

And the browser may come to understand not only how to display HTML, but also where streamed HTML should be inserted.

If this responsibility split progresses, frontend architecture may become more hybrid.

Especially for SPAs, there may be another path beyond

Fetch JSON and render on the client

Instead, we may also be able to

Fetch / stream HTML partials and update via browser-native behavior

I do not see this as the end of SPAs. I see it as something that may expand what SPAs can do.

This is still experimental, so it is not an API to use in production right away.

But the direction where HTML changes from “a document loaded once at the beginning” into “a UI unit that can be streamed, replaced, and updated” feels very important for the future of frontend development.

DPU is definitely something to keep an eye on. 😺

References

https://developer.chrome.com/blog/declarative-partial-updates?hl=en

https://github.com/WICG/declarative-partial-updates

https://github.com/GoogleChromeLabs/template-for-polyfill

https://github.com/GoogleChromeLabs/html-setters-polyfill

https://github.com/nyaomaru/declarative-partial-updates-sample

The Difference Between satisfies, as, and Generics in TypeScript

nyaomaru — Wed, 17 Jun 2026 12:43:50 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who recently obsessed with playing video game of "inscryption". 🃏

In TypeScript, there are several syntaxes that look like they are "specifying a type."

For example:

as
satisfies
generics using T extends xxx

But these are not the same thing.

Roughly speaking:

as asks TypeScript to trust you
satisfies asks TypeScript to check the value
generics let you encapsulate that check inside an API

They all look type-related, but the responsibility lives in different places.

You may see AI-generated code overusing as, or codebases using satisfies casually, or libraries using generics to enforce stricter APIs. These patterns appear quite often in real-world development.

In this article, I want to explain the difference between as, satisfies, and generics not as "ways to specify a type," but as ways to decide where type responsibility should live.

Let's jump in.

🙏 `as` asks TypeScript to trust you

In TypeScript, as lets you tell the compiler:

Please treat this value as this type, please 😭

For example, the runtime value below is still a string, but TypeScript treats it as a number.

const value = "123" as unknown as number;

console.log(typeof value); // "string"

value.toFixed();
// TypeScript thinks this is a number, so there is no compile-time error.
// But at runtime, this throws: "value.toFixed is not a function"

The important point is 👇

as does not transform the runtime value.

So using it for external data can be very dangerous.

type User = {
  id: string;
  name: string;
};

const user = JSON.parse(input) as User;

This does not check whether the parsed value is actually a User.

It only tells TypeScript:

Trust me. This is a User. Maybe.

In other words, as is for cases where a human knows something TypeScript cannot know.

It is useful, but it does not guarantee anything by itself.

If you write as, the responsibility is on you.

🔍 `satisfies` asks TypeScript to check the value

Now let's look at satisfies, which was introduced in TypeScript 4.9.

type RouteConfig = Record<
  string,
  {
    path: string;
    label: string;
  }
>;

const routes = {
  home: {
    path: "/",
    label: "Home",
  },
  about: {
    path: "/about",
    label: "About",
  },
} satisfies RouteConfig;

With this, TypeScript checks whether the declared value matches the expected type structure.

For example, if you add a property that does not exist on a route item, TypeScript reports an error.

const routes = {
  home: {
    path: "/",
    label: "Home",
  },
  about: {
    path: "/about",
    label: "About",
    nyaomaru: "cat", // Type error: nyaomaru does not exist on the route item type 😼
  },
} satisfies RouteConfig;

The interesting part is 👇

Even though routes is checked against RouteConfig, the type of routes itself is not collapsed into RouteConfig.

routes is checked as RouteConfig.

But the inferred type of routes remains close to the actual object literal you wrote.

So keyof typeof routes becomes the union of the actual keys, not just string.

type RouteName = keyof typeof routes;
// "home" | "about"

In other words, satisfies checks that a value satisfies a given type while preserving the original inference as much as possible.

Compare that with a regular type annotation.

const routes: RouteConfig = {
  home: {
    path: "/",
    label: "Home",
  },
  about: {
    path: "/about",
    label: "About",
  },
};

type RouteName = keyof typeof routes;
// string

When you annotate routes as RouteConfig, TypeScript treats it as RouteConfig.

Since RouteConfig is a Record<string, ...>, RouteName becomes string.

So when you want to validate a value against a type while keeping the concrete information from the actual value, satisfies is often a better fit.

In short:

satisfies checks that a value matches a type without unnecessarily widening the value's inferred type.

🎁 Generics encapsulate the check inside an API

At this point, you might think:

Okay, then I should just use satisfies everywhere. 😹

And yes, sometimes that works well.

But writing satisfies every time can be annoying.
And if someone forgets to write it, the intended check disappears.

So what if we move that check into a function?

That is where generics come in.

As a quick recap, we could write this

const routes = {
  home: {
    path: "/",
    label: "Home",
  },
} satisfies RouteConfig;

But we can also wrap the pattern inside a function using generics.

function defineRoutes<const T extends RouteConfig>(routes: T) {
  return routes;
}

const routes = defineRoutes({
  home: {
    path: "/",
    label: "Home",
  },
});

Nice and clean.

Now we get:

validation that the value matches RouteConfig
preservation of the concrete key "home"
no need for users to write satisfies every time

But then this appears

<const T extends RouteConfig>

What is going on here???

Let's break it down.

T extends RouteConfig means: "T must be assignable to RouteConfig."
const T asks TypeScript to infer object literals and array literals as narrowly as possible.

Here, const is not the same as a const variable declaration.

It is not about whether a value can be reassigned.

It is about making generic type parameter inference preserve literal information as much as possible.

📊 Comparing the three with config objects

Here is the comparison so far.

Syntax	What it does	Main responsibility
`as Type`	Asks TypeScript to believe the value is that type	The person writing the code
`satisfies Type`	Checks whether the value matches the type	The value declaration
`<T extends Type>`	Constrains what an API can accept	The API designer

So, in casual terms:

as means: "Trust me. 🙏"
satisfies means: "Please check if this is correct. 🔍"
generics mean: "Only pass values that fit this API. 🎁"

So far, we have looked at config objects.

But in real-world development, this difference becomes even more important when dealing with external data.

API responses, localStorage, URL params, and form input cannot be protected by TypeScript types alone.

For those values, we need runtime guards.

And once we start writing runtime guards by hand, another problem appears 👇

The existing TypeScript type and the handwritten schema can drift apart.

🤔 Thinking through `typedStruct`

This becomes easier to understand if we use a small validator API as an example.

I'll use my type guard library, is-kit.

nyaomaru / is-kit

Lightweight, zero-dependency toolkit for building `isFoo` style type guards in TypeScript. Runtime-safe 🛡️, composable 🧩, and ergonomic ✨. npm -> https://www.npmjs.com/package/is-kit

is-kit

is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards.

It helps you write small isFoo functions, compose them into richer runtime checks, and keep TypeScript narrowing natural inside regular control flow.

Runtime-safe 🛡️, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow.

Build and reuse typed guards
Compose guards with and, or, not, oneOf
Validate object shapes and collections
Parse or assert unknown values without a large schema framework

📚 Documentation Site

Best for app-internal narrowing, filtering, and reusable guards.

🤔 Why use `is-kit`?

Tired of rewriting the same isFoo checks again and again?

is-kit is a good fit when you want to:

write reusable isX functions instead of one-off inline checks
keep runtime validation lightweight and dependency-free
narrow values directly in if, filter, and other TypeScript control flow
compose validation logic…

View on GitHub

is-kit is a lightweight library for building small type guards like isString and isNumber, then composing them with helpers like and, or, and struct, while still allowing TypeScript narrowing to work naturally.

Suppose an external API returns a User like this

type User = {
  id: string;
  name: string;
};

With a normal struct, we can create a guard for that object shape.

const isUser = struct({
  id: isString,
  name: isString,
});

This is useful.

struct can infer the return type from the schema, so isUser can validate a value that looks like a User.

But there is one problem.

It is easy for the schema and the existing type to drift apart.

For example, suppose the User type already exists, but we accidentally write the wrong key in the schema.

type User = {
  id: string;
  name: string;
};

const isUser = struct({
  id: isString,
  displayName: isString,
});

This struct call itself is valid.

From the perspective of struct, this is a perfectly valid schema for:

{
  id: string;
  displayName: string;
}

So struct is useful for creating a type from a schema.

But it does not synchronize that schema with an existing User type.

A common dangerous workaround is to use as.

const isUser = struct({
  id: isString,
  displayName: isString,
}) as Predicate<User>;

This is extremely dangerous. ⚠️⚠️⚠️

The schema says displayName, but we are telling TypeScript

Trust me. This is a guard for User. Please 🙏

That as is not a check.

It is just a self-declaration.

Now, satisfies can improve this.

If the library exposes a schema shape type, we could write something like:

const userSchema = {
  id: isString,
  name: isString,
} satisfies TypedStructShape<User>;

Now TypeScript checks whether the schema corresponds to User.

If we write an unknown key or forget a required key, TypeScript can report an error.

const userSchema = {
  id: isString,
  displayName: isString,
  // name is missing, and displayName does not exist on User
} satisfies TypedStructShape<User>;

This is better.

But writing this every time is a bit annoying.

Also, if the user forgets to write satisfies TypedStructShape<User>, the schema and the type can drift apart again.

So we can use generics to encapsulate this check inside the API.

const isUser = typedStruct<User>()({
  id: isString,
  name: isString,
});

With this shape, users do not need to write satisfies TypedStructShape<User> every time.

Instead, the typedStruct<User>() API itself checks 👇

Does this schema correspond to User?

So, using the framing from earlier:

we are not using as to ask TypeScript to trust us
we are not asking users to write satisfies every time
we are using generics to encapsulate the check inside an API

That is the core idea.

Let's look a little more concretely.

The implementation idea for typedStruct looks like this:

type OptionalKeys<T> = {
  // WHY: Optional keys accept an empty object when picked in isolation.
  [K in keyof T]-?: {} extends Pick<T, K> ? K : never;
}[keyof T];

type RequiredKeys<T> = Exclude<keyof T, OptionalKeys<T>>;

type TypedStructShape<T extends object> = {
  readonly [K in Extract<RequiredKeys<T>, string>]-?: Predicate<T[K]>;
} & {
  readonly [K in Extract<OptionalKeys<T>, string>]-?: OptionalSchemaField<
    Predicate<T[K]>
  >;
};

type NoExtraKeys<S, Shape> = S & {
  readonly [K in Exclude<keyof S, keyof Shape>]: never;
};

type TypedStructFields<
  T extends object,
  S extends TypedStructShape<T>,
> = NoExtraKeys<S, TypedStructShape<T>>;

export function typedStruct<T extends object>() {
  return <const S extends TypedStructShape<T>>(
    fields: TypedStructFields<T, S>,
    options?: { exact?: boolean },
  ): Predicate<InferSchema<TypedStructFields<T, S>>> =>
    // WHY: `typedStruct` keeps `struct` runtime behavior while using the target
    // type only to check that hand-written guard fields stay in sync.
    struct(fields, options);
}

We can ignore the small details for now.

The important part is this:

typedStruct<T extends object>()

First, typedStruct receives the target type T.

Then this part:

<const S extends TypedStructShape<T>>

means the actual schema S passed by the user must correspond to T.

But here is an important detail

S extends TypedStructShape<T> alone cannot completely prevent extra keys.

TypeScript uses structural typing.

If a type has the required properties, it may still satisfy a constraint even if it also has additional properties.

For example, if User is { id: string; name: string }, then a schema like { id, name, displayName } has all required keys and one extra key.

The constraint S extends TypedStructShape<User> alone may still allow that.

So we use NoExtraKeys to make keys that do not exist in TypedStructShape<T> become never.

Now let's look at how TypedStructShape<T> works.

It separates required keys and optional keys from T.

type OptionalKeys<T> = {
  [K in keyof T]-?: {} extends Pick<T, K> ? K : never;
}[keyof T];

type RequiredKeys<T> = Exclude<keyof T, OptionalKeys<T>>;

OptionalKeys<T> is used to pick optional properties like name?: string.

Then TypedStructShape<T> treats the keys differently:

required keys become Predicate<T[K]>
optional keys become OptionalSchemaField<Predicate<T[K]>>

That means if a key is optional in the target type, the schema must also mark it as optional using something like optionalKey(...).

type TypedStructShape<T extends object> = {
  readonly [K in Extract<RequiredKeys<T>, string>]-?: Predicate<T[K]>;
} & {
  readonly [K in Extract<OptionalKeys<T>, string>]-?: OptionalSchemaField<
    Predicate<T[K]>
  >;
};

Here, OptionalSchemaField is the internal type used to represent a schema field created by a helper like optionalKey(...).

Next, TypedStructFields<T, S> prevents schema fields from having keys that do not exist in T.

Roughly speaking, NoExtraKeys takes keys that exist in S but not in Shape, and turns them into never.

For example, if User does not have displayName, but the schema includes displayName, that field becomes never.

Since a normal guard cannot be assigned to never, TypeScript rejects the extra key.

type NoExtraKeys<S, Shape> = S & {
  readonly [K in Exclude<keyof S, keyof Shape>]: never;
};

type TypedStructFields<
  T extends object,
  S extends TypedStructShape<T>,
> = NoExtraKeys<S, TypedStructShape<T>>;

So typedStruct is not just a helper that adds a type to struct.

It is an API for making an existing object type and a handwritten runtime guard harder to drift apart.

One important point 👇

typedStruct does not automatically generate a runtime validator.

TypeScript types do not exist at runtime.

Also, we cannot automatically generate isString or isNumber from the User type.

So the guard itself still has to be written by hand.

const isUser = typedStruct<User>()({
  id: isString,
  name: isString,
});

But the API can check whether the handwritten schema is still in sync with User.

It's the tasty part of typedStruct.

This is especially useful when you already have API response types generated from something like OpenAPI.

Here, imagine ApiResponse is a generated response type.

type ArticleResponse = ApiResponse<"/articles/{id}", "get">;

const isArticleResponse = typedStruct<ArticleResponse>()({
  id: isNumber,
  title: isString,
  summary: optionalKey(isString),
});

Here, optionalKey(isString) means the object key itself may be missing.

But if the key exists, the value must pass isString.

So as a runtime check, this does not allow { summary: undefined }.

It means:

if summary exists, it must be a string
if summary does not exist, that is OK

This is a small but important distinction.

The idea is not ❌

The TypeScript property is optional, so I can omit the schema field.

Instead, the idea is ✅

The runtime guard should explicitly say that this key is optional.

That way, when the target type changes, the mismatch becomes easier to notice.

Also, the compile-time key check in typedStruct and the runtime check in struct(..., { exact: true }) are different things.

const isUser = typedStruct<User>()(
  {
    id: isString,
    name: isString,
  },
  { exact: true },
);

NoExtraKeys is a compile-time check that prevents the schema author from writing extra keys in the schema.

On the other hand, { exact: true } is a runtime check that rejects actual runtime objects if they contain keys outside the schema.

They may look similar, but they check different things.

NoExtraKeys checks mistakes in the handwritten schema
{ exact: true } checks extra keys in runtime data

This is exactly the theme of the article.

Instead of silencing TypeScript with as, we take a satisfies-like check and encapsulate it inside an API with generics.

One more important design point 👇

The return type is not directly forced to T.

Instead, it is inferred from the actual fields passed to the function.

Predicate<InferSchema<TypedStructFields<T, S>>>;

So T is used to check whether the schema is in sync with the existing type.

But the actual guard type is inferred from the schema, just like struct.

In other words, we are not doing this

as Predicate<User>

Instead, the existing type synchronization is handled by the generic constraint, while the actual guard type is derived from the schema.

🎯 Summary

In this article, we looked at the difference between as, satisfies, and generics through the lens of where type responsibility lives.

Syntax	Role	Where the responsibility lives
`as Type`	Asks TypeScript to trust you 🙏	The person writing the code
`satisfies Type`	Checks whether a value matches a type 🔍	The value declaration
`<T extends Type>`	Constrains what an API accepts 🎁	The API designer

as is not evil.

Sometimes TypeScript cannot know something, and a human has to take responsibility for that missing information.

But as is not a check.

When you use as for external data or handwritten schemas, the code can look type-safe while skipping the actual validation.

AI-generated code often papers over uncertainty with as, so this is something worth watching for.

When you really want to check whether a value has the right shape, first consider whether satisfies can help.

And when you find yourself repeating the same satisfies pattern again and again, consider moving that constraint into an API with generics.

Personally, I find this framing useful:

as means: "Trust me."
satisfies means: "Please check if this is correct."
generics mean: "Only pass values that fit this API."

typedStruct in is-kit is a good example of this difference.

When you want to keep an existing object type and a runtime guard in sync, do not silence TypeScript with as.

Instead, you can take a satisfies-like check and encapsulate it inside an API using generics.

This makes the safer way the natural way to use the API, and moves type responsibility closer to the API design.

Happy TypeScript life. 🫰

Bonus

The user-defined type guard library used in this article is is-kit.

nyaomaru / is-kit

Lightweight, zero-dependency toolkit for building `isFoo` style type guards in TypeScript. Runtime-safe 🛡️, composable 🧩, and ergonomic ✨. npm -> https://www.npmjs.com/package/is-kit

is-kit

is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards.

It helps you write small isFoo functions, compose them into richer runtime checks, and keep TypeScript narrowing natural inside regular control flow.

Runtime-safe 🛡️, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow.

Build and reuse typed guards
Compose guards with and, or, not, oneOf
Validate object shapes and collections
Parse or assert unknown values without a large schema framework

📚 Documentation Site

Best for app-internal narrowing, filtering, and reusable guards.

🤔 Why use `is-kit`?

Tired of rewriting the same isFoo checks again and again?

is-kit is a good fit when you want to:

write reusable isX functions instead of one-off inline checks
keep runtime validation lightweight and dependency-free
narrow values directly in if, filter, and other TypeScript control flow
compose validation logic…

View on GitHub

typedStruct was added in v1.8, so please give it a try. 😻

CHANGELOG.md is for Both Humans and AI Now, So Let’s Automate It

nyaomaru — Wed, 03 Jun 2026 12:33:59 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who recently discovered the deliciousness of a cheese whose name sounds a bit like Al Capone. 🧀

Are you building personal projects?

Or contributing to OSS?

Or maybe you are busy playing Resident Evil 9 🧟 and CloverPit 🍀?

Whatever the case, I respect your admirable dedication as an engineer.

Now, when managing OSS on GitHub, one file that becomes very important is CHANGELOG.md.

Why is it important?

For example, when a library I use gets updated, the first thing I usually check is CHANGELOG.md.

Recently, I have been experimenting with an AI triage workflow. For Dependabot updates, I feed release notes and CHANGELOG.md into AI, then ask Claude Code to evaluate the risk and help with triage.

This has been very useful. I do not have to check everything manually, and that makes me happy 😺

In other words, CHANGELOG.md is becoming a document that is not only read by humans, but also read by AI as input for dependency update decisions.

So, CHANGELOG.md will continue to be very useful in the coming era.

But surprisingly, many projects do not maintain it well.

For example, even some very useful React development tools sometimes ship silent releases without any release notes at all.

When that happens, users have to dig through commit history and figure out things like:

What new features were added?
What changed?
Is it safe to upgrade?

Of course, busy engineers do not have time for that. I am not that busy, but if I had that time, I would rather play CloverPit 🍀.

So, to protect my precious game time, I built an OSS tool that automatically generates CHANGELOG.md.

nyaomaru / changelog-bot

Automatic create changelog with AI. 🤖 It provides CLI and github actions. 🚀 https://www.npmjs.com/package/@nyaomaru/changelog-bot

Releases should feel exciting, not tedious.

@nyaomaru/changelog-bot 🤖 turns your Git history and release notes into a polished changelog entry (and optional PR) in a single run. Drop it into CI, run it locally, or hand it to your release captain—either way, you ship with a crisp changelog and zero copy-paste fatigue.

Why changelog-bot?

Automated storytelling: Combines commit history, PR titles, and release notes to produce human-ready changelog sections.
LLM superpowers (optional): Connect OpenAI or Anthropic for tone-aware summaries or skip API keys entirely and rely on a robust heuristic fallback.
PR-ready output: Can open a pull request with updated changelog, compare links, and release notes already wired up.
Safe defaults: Detects duplicate versions, keeps compare links current, and won’t fail a release if AI is down.
CI-native: Works as a GitHub Action, reusable workflow, or plain CLI—no fragile scripting required.

Important

This project is currently in its early stages…

View on GitHub

In this article, I will walk through the changes from v0.1 and what I am planning next.

Let’s take a look!

🤖 What is changelog-bot?

changelog-bot is a CLI and GitHub Action that automatically creates a Pull Request to update CHANGELOG.md based on Git history, Pull Requests, and GitHub Release Notes.

What it does is simple:

Collect commits and PRs from the previous release to the current release
Categorize changes into sections such as Added, Changed, Fixed, Docs, and Chore
Add a new release section to CHANGELOG.md
Create a Pull Request with that change

If you configure an AI provider, it can use OpenAI, Anthropic, or Gemini to generate a more readable changelog section.

On the other hand, it also works with a fallback mode when no API key is provided.

So it is totally fine even if you do not use AI.

In other words, this is not:

A tool that can do nothing without AI.

It is more like:

An automation tool that works better with AI.

That is the key idea.

🐾 What was available up to v0.1

Up to v0.1, I focused on building the foundation of changelog-bot.

It already supported:

CLI and GitHub Action usage
Changelog generation from Git history
Importing GitHub Release Notes
OpenAI and Anthropic providers
Heuristic fallback
Dry-run mode

At this point, the basic experience was already there:

Automatically update CHANGELOG.md during a release workflow.

I also introduced it in this earlier article:

nyaomaru

Nov 30 '25

Generate CHANGELOG.md Automatically 🤖

#ai #typescript #ci #opensource

3 min read

But there were still some problems.

In particular, even though users could choose an AI provider, there was still no strong way to adjust the language or writing style of the generated CHANGELOG.md for each project.

For example, there was no good way to pass project-specific rules such as:

“Write it in Japanese.”
“Group internal changes under Chore.”
“Group dependency updates together.”

So the customization experience was still weak.

🚀 v0.2: Gemini provider support

In v0.2, I added Gemini as a new LLM provider.

Now changelog-bot supports these three providers:

OpenAI
Anthropic
Gemini

You can specify Gemini from the CLI like this:

changelog-bot \
  --provider gemini \
  --release-tag HEAD \
  --release-name 0.2.0 \
  --dry-run

You can also use it from GitHub Actions:

with:
  provider: gemini
env:
  GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}

I also added dry-run diagnostics.

Provider: gemini
Model: gemini-3.5-flash
AI used: true
Fallback reasons: none

This makes it easier to check whether the AI provider was actually used, or whether changelog-bot fell back to the heuristic mode.

It is a small feature, but I think this kind of observability is very important for CI tools.

When something runs in CI, you want to quickly understand what actually happened.

🚀 v0.3: Changelog customization

In v0.3, I added customization support for changelog generation.

The newly added options are:

Option	Description
`--language`	Specifies the language of the generated `CHANGELOG.md`
`--instructions`	Passes inline instructions to the AI
`--instructions-file`	Passes instructions to the AI from a file

For example, if you want to generate a changelog in Dutch, you can write:

changelog-bot \
  --provider gemini \
  --release-tag HEAD \
  --release-name 0.3.0 \
  --language nl \
  --instructions "Schrijf kort en duidelijk in het Nederlands. Groepeer interne wijzigingen onder Chore." \
  --dry-run

You can also define project-specific rules in a file.

changelog-bot \
  --provider openai \
  --release-tag HEAD \
  --release-name 0.3.0 \
  --language nl \
  --instructions-file .github/changelog-instructions.md \
  --dry-run

For example, .github/changelog-instructions.md can contain rules like this:

Write concise release notes in Dutch.

Rules:

- Focus on user-facing changes.
- Group internal refactors under Chore.
- Group dependency updates together.
- Avoid mentioning commit hashes.

With this, changelog-bot is no longer just “a tool that generates changelogs with AI.”

It is moving toward:

A tool that can generate a CHANGELOG.md that feels right for each project.

Also, when customization is enabled, changelog-bot does not simply use GitHub Release Notes as-is, even if they exist.

Instead, it passes them to the model and lets the model rewrite them.

This means GitHub Release Notes can still be used as source material, while the final output reflects the specified language and instructions.

🥌 Roadmap toward v1

With customization added in v0.3, the shape of v1 is becoming much clearer.

Here are the main things I want to add before v1.

1. Config file support

Passing CLI options every time is annoying, so I want to support config files.

{
  "provider": "gemini",
  "language": "nl",
  "instructionsFile": ".github/changelog-instructions.md"
}

The goal is to make the same configuration usable from the CLI, GitHub Actions, and reusable workflows.

2. Choosing behavior when an AI provider fails

Right now, changelog-bot falls back when an AI provider fails.

This is convenient, but some projects may want the workflow to fail if AI generation fails.

So I am considering options like:

--fail-on-llm-error
--require-provider
--no-ai

Since changelog-bot is intended to be used in CI, users should be able to choose between:

“Fail when AI generation fails”
“Fallback and continue”

Both behaviors are valid depending on the project.

3. JSON report output

Dry-run diagnostics already exist, but I also want to add a JSON report.

changelog-bot --dry-run --report-json

For example, it would be useful to output machine-readable information such as:

provider
model
aiUsed
fallbackReasons
generated sections
PR title
labels

This should make it easier to integrate changelog-bot with other CI tools and bots.

4. Better changelog quality

I also want to keep improving the quality of the generated changelog.

Some areas I want to improve are:

Grouping dependency updates
Detecting breaking changes
Label-based include / exclude rules
Custom section names
Better duplicate detection

Especially in OSS, what should be included in a changelog differs from project to project.

I want changelog-bot to handle those differences better.

🎯 Summary

CHANGELOG.md is a very plain file, but for users, it is an important document.

Recently, it is also becoming more common to let AI read it and use it as input for dependency update decisions.

That is why CHANGELOG.md should not just be generated somehow.

It should be generated in a readable way that fits each project’s context.

But writing it carefully by hand every time is honestly a pain.

changelog-bot is a tool for automating that process with Git history, Pull Requests, GitHub Release Notes, and AI.

In v0.2, I added Gemini support.

In v0.3, I added customization through language, instructions, and instructions file.

With these changes, changelog-bot is moving from:

Just generating a changelog automatically

to:

Generating a changelog that fits each project

v1 is getting closer.

If you are interested, please give the repository a ⭐ and watch over it warmly!

nyaomaru / changelog-bot

Automatic create changelog with AI. 🤖 It provides CLI and github actions. 🚀 https://www.npmjs.com/package/@nyaomaru/changelog-bot

Releases should feel exciting, not tedious.

Why changelog-bot?

Automated storytelling: Combines commit history, PR titles, and release notes to produce human-ready changelog sections.
LLM superpowers (optional): Connect OpenAI or Anthropic for tone-aware summaries or skip API keys entirely and rely on a robust heuristic fallback.
PR-ready output: Can open a pull request with updated changelog, compare links, and release notes already wired up.
Safe defaults: Detects duplicate versions, keeps compare links current, and won’t fail a release if AI is down.
CI-native: Works as a GitHub Action, reusable workflow, or plain CLI—no fragile scripting required.

Important

This project is currently in its early stages…

View on GitHub

Now let’s auto-generate our CHANGELOG.md files and use the saved time to play some games! 🧟🍀

DEV Community: nyaomaru

Learn Trapping Rain Water, Top K Frequent and Selection Sort with Step-by-Step Visualization in DSA View View 👀👀

🌧️ Trapping Rain Water

How Much Water Fits Above One Position?

Two Pointers

Start From Both Ends

Now We Can Trap Water

Why Can We Process the Shorter Side?

Complexity

👀 Let's View View It

🔢 Top K Frequent Elements

First, Count Everything

Use Frequency as an Index

Implementation

Step 1: Build the Frequency Map

Step 2: Put Values Into Buckets

Step 3: Read From Highest Frequency

Why Is This Interesting?

Complexity

👀 Let's View View It

👉 Selection Sort

First Pass

Repeat

Implementation

Why Is It Called Selection Sort?

Complexity

👀 Let's View View It

🧠 What Did We Actually Learn?

Trapping Rain Water

Top K Frequent Elements

Selection Sort

🎯 Conclusion

nyaomaru / dsa-view-view

DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free.

DSA View View

Why Try It?

Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step Visualization in DSA View View 👀👀

🏝️ Number of Islands

Find One Land, Then Explore All Connected Land

Why Do We Change 1 to 0?

Why Four Recursive Calls?

The Base Cases

Let's Follow Two Islands

Complexity

👀 Let's View View It

🌳 Invert Binary Tree

Go Down First

The Important Part: The Swap Happens on the Way Back

A Slightly Bigger Example

Complexity

👀 Let's View View It

🎓 Course Schedule

Build the Graph

What Is graph?

What Is indegree?

Start With Courses That Need Nothing

Finish Course 0

Finish Course 1

Finish Course 2

Why Does This Detect a Cycle?

Another Example

Why Use head Instead of shift()?

Complexity

👀 Let's View View It

🧠 What Did We Actually Learn?

Number of Islands

Invert Binary Tree

Course Schedule

🎯 Conclusion

nyaomaru / dsa-view-view

DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free.

DSA View View

Why Try It?

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in DSA View View 👀👀

🥞 Valid Parentheses

Use a Stack

What About an Invalid Example?

Complexity

👀 Let's View View It

🔗 Reverse Linked List

Why Do We Change `1` to `0`?

What Is `graph`?

What Is `indegree`?

Why Use `head` Instead of `shift()`?

Step 3: Move `prev`

Step 4: Move `current`

`define`

`equalsKey`

`or`