DEV Community: Amar Gul

Backpropagation Is Just Dynamic Programming (I Animated It to Prove It)

Amar Gul — Wed, 01 Jul 2026 13:51:53 +0000

Everyone learns backpropagation as "apply the chain rule." Almost nobody explains why it's fast — and that "why" is the whole reason deep learning is computationally possible at all.

So I animated one full training step to show the part most explanations skip.

What you're actually seeing

Forward pass: a single signal travels through 3 weights → a prediction → compared to the target = the loss.
Backward pass: the error (δ) flows back through the network. δ₃ is computed at the output, then reused to get δ₂, which is reused to get δ₁ — never recalculated from scratch.
The point: one forward pass + one backward pass produces every weight's gradient with zero redundant work, no matter how deep the network goes.

That reuse — store a result once, reuse it instead of recomputing — is the exact definition of dynamic programming. The only difference from a Fibonacci memo is that the stored value is a derivative.

The stack

React (a phase state machine: idle → forward → loss → backward → done)
Framer Motion for the signal particles and edge transitions
Web Audio API — every tone is synthesized, no audio files
Deterministic timing so each run records identically for video

Three things that were trickier than expected

1. My animated particle was blinking on every frame

The signal dot flickered constantly. The cause: I'd defined the particle component inside the main component, so every state update created a new function identity and React remounted it.

// ❌ inside the component → new identity each render → remount → blink
function Backprop() {
  function FlowParticle() { /* ... */ }
}

// ✅ module scope → stable identity → smooth animation
function FlowParticle({ x1, y1, x2, y2, color, particleKey }) {
  return <motion.circle /* ... */ />;
}

Lifting it to module scope fixed it instantly.

2. The sound wouldn't play

Browsers block audio that isn't triggered by a user gesture — an AudioContext starts in a suspended state. The fix is to create it lazily and resume() it on the first real click:

function getAudio() {
  if (!audioRef.current) {
    const Ctx = window.AudioContext || window.webkitAudioContext;
    if (Ctx) audioRef.current = new Ctx();
  }
  return audioRef.current;
}

function handleStart() {
  const ctx = getAudio();
  if (ctx && ctx.state === "suspended") ctx.resume(); // unlock on gesture
  startCountdown();
}

3. Syncing a fixed-timer animation to a recorded voiceover

This was the real headache. The narration isn't uniform — it lingers on δ₃ and the first gradient, then races from δ₂ to δ₁. One global delay constant couldn't fit that, so every beat got its own duration:

// ms each ∂L/∂w stays on screen, keyed by edge — w₂ is short so δ₁
// lands right on "delta one"; w₁ is long so all gradients hold
// through the dynamic-programming wrap.
const GRAD_HOLD_BY = { 2: 8500, 1: 1000, 0: 14000 };
const gradMs = (edge) => GRAD_HOLD_BY[edge] ?? T.gradCalc;

One more gotcha: setTimeout gets throttled when the tab loses focus, so the animation drifts during a long take. Keep the recording tab foregrounded.

What I learned

The chain rule was always true — backpropagation is just the dynamic-programming version of it. Reframing it that way made it click in a way "here's the partial derivative" never did.
Building the network data-driven (one HIDDEN constant drives the layout, math, and animation) meant I could change depth without touching the render code.
For explainer animations, deterministic, hand-tunable timing beats physics-based motion every time — you need each beat to land on a spoken word.

Watch it

🎥 Full 2-minute walkthrough: https://youtu.be/ZV5HKbCsdfo

This is part of my "AI, Visualized" series — neural networks → gradient descent → backprop, with Transformers next. What should I animate after that? 👇

I Visualized Why AI Models Fail to Train — It's One Number

Amar Gul — Tue, 23 Jun 2026 18:27:19 +0000

Every AI model on earth learns the same way: by rolling downhill. And the single most common reason a model fails to learn comes down to one number — the learning rate. So I built an animation that runs the exact same gradient descent three times, from the identical starting point, changing only that number.

What you're actually seeing

A loss curve — height is how wrong the model's prediction is. The ball starts high (a random guess); the goal is the bottom.
The cyan tangent line is the gradient — the slope under the ball. It points uphill, so the algorithm steps the opposite way.
Three runs, one variable: too low (crawls, never arrives), tuned (settles dead-on the global minimum), too high (overshoots, swings, never settles — divergence).
A deliberate second dip on the left — a local minimum, the trap a too-cautious model can get stuck in.

The stack

React (a small phase state machine: idle → gradient → step → done), Framer Motion for the ball + tangent, the Web Audio API for synthesized tones (no asset files), and deterministic, recording-friendly timing so every take is identical.

Three things that were trickier than expected

1. The SVG ball stuttered until I stopped animating `cx`/`cy`

Animating an SVG circle's cx/cy attributes is janky — they're not GPU-composited. The fix is to keep the circle at the origin and animate its transform (x/y) instead, which Framer Motion springs smoothly:

<motion.circle
  cx={0}
  cy={0}
  r={10}
  animate={{ x: sx(ballX), y: sy(L(ballX)) }}
  transition={{ type: "spring", stiffness: 110, damping: 16 }}
/>

sx/sy map math-space (weight, loss) to screen-space pixels.

2. Recording needs identical-length runs — so I drift-corrected the clock

setTimeout drifts: a loop of await delay(2000) slowly desyncs because each step also pays for render time. For a video where every run must be the same length, I pin each step to an absolute wall-clock budget instead of a relative sleep:

// Sleep until `targetMs` have elapsed since the run started — not "wait N ms".
function waitUntil(targetMs) {
  const remaining = targetMs - (Date.now() - runStartRef.current);
  return after(Math.max(remaining, 0));
}
// ...inside the loop:
await waitUntil((step + 1) * STEP_BUDGET_MS);

Any per-step jitter gets absorbed, so the run always lands on the same total duration.

3. A stale closure made my "auto" sequence ignore the learning rate

To record all three runs hands-free, I built a choreographed sequence that flips the learning-rate preset between runs. It silently used the wrong rate every time. The culprit: the descent loop read the lr React state directly, but that value was captured once when the async sequence started — classic stale closure. The fix is to pass the rate in as an argument instead of reading state mid-flight:

// Before: read `lr` from state inside the loop → frozen at sequence start.
// After: the caller passes the rate explicitly.
async function runDescent(rate = lr) {
  // ...
  x = x - rate * gradient; // uses the rate for THIS run, not a stale one
}

await runDescent(0.02); // low
await runDescent(0.46); // good
await runDescent(0.6);  // high

What I learned

The whole lesson of the video is a one-liner in code: x = x - rate * gradient. Everything dramatic on screen is that single update, looped.
Designing the loss landscape was its own mini-problem — I needed a function with a shallow local minimum and a deeper global one so "stuck in a local min" is visible at a glance. A tilted double-well quartic did it.
Synthesizing audio whose pitch tracks the loss makes the descent audible — you can hear it settle (or never settle) with your eyes closed.

Watch / try it

🎥 Full walkthrough: https://youtu.be/wng0ddn0wPo

I'm animating a series — neural network training ✅, gradient descent (this one), and backpropagation is next. What should I visualize after that — transformers, CNNs, or something classic like Dijkstra? 👇

I Built a Neural Network You Can Watch Train — Forward Pass, Loss, and Backprop, Animated

Amar Gul — Sat, 20 Jun 2026 17:36:00 +0000

Every neural-network tutorial I tried threw equations at me before I ever saw what was actually happening. I wanted the reverse: watch the activations flow forward, watch the loss bars shrink, watch backprop push gradients right-to-left across the layers.

So I built it. Here's a neural network that trains itself in front of you 👇

What you're actually seeing

Forward pass — particles flow left → right as activations propagate through the layers.
Loss — bars drop each epoch, and the output neurons glow red → gold → green as the error shrinks.
Backpropagation — particles flow right → left, the gradient returning toward the input.
9 epochs, deterministically timed so every run is identical.

No training data is harmed in the making of this animation — it's a faithful visual model of the phases, built for intuition, not for crunching MNIST.

The stack

React for the phase state machine: idle → forward → loss → backward → done
Framer Motion for the particle and node animations
Web Audio API for synthesized sound (no audio files), tied to the dot movement
A small drift-corrected timing loop so the whole run lands on a fixed wall-clock budget

Three things that were trickier than expected

1. Animate particles with CSS transforms, not SVG attributes

My first version animated each particle's cx/cy. It worked but stuttered. Switching to Framer Motion's x/y (which compile to GPU-friendly CSS transforms) made it buttery:

<motion.circle
  r={4}
  cx={0} cy={0}
  initial={{ x: x1, y: y1, opacity: 0, scale: 0 }}
  animate={{ x: [x1, x2], y: [y1, y2], opacity: [0, 1, 1, 0] }}
  transition={{ duration: 0.65, ease: "easeInOut" }}
/>

2. Backprop has to flow backward

Sounds obvious, but my first pass spawned the backprop particles in the same direction as the forward pass. The fix was just swapping the source/target layer so the dots travel from the deeper layer back toward the input:

// Forward: layer l-1 → l   (left → right)
spawnParticles(l - 1, l, FORWARD_COLOR);

// Backprop: layer l → l-1  (right → left)
spawnParticles(l, l - 1, BACKWARD_COLOR);

Tiny change, huge difference in how "correct" it reads.

3. Make the network show it's learning

Loss bars are fine, but I wanted the network itself to react. So the output nodes are colored by the current loss — the same thresholds as the bars, so the legend stays consistent:

function lossColor(loss) {
  if (loss < 0.15) return GREEN;   // basically trained
  if (loss < 0.40) return GOLD;
  return RED;                       // high error
}

Early epochs glow red; by the end they settle into green. You see the network heal.

Bonus: deterministic timing (so I could record it)

setInterval drift made every recording a slightly different length. I anchored a start timestamp and held each epoch to a fixed budget, correcting drift as it goes:

function waitUntil(targetMs) {
  const remaining = targetMs - (Date.now() - runStart);
  return sleep(Math.max(remaining, 0));
}
// ...end of each epoch:
await waitUntil((epoch + 1) * EPOCH_BUDGET_MS);

Now every run lands on the same total time regardless of frame jitter.

What I learned

Animation isn't decoration — putting the direction of data flow on screen taught me backprop better than any equation did.
Browsers block the Web Audio API until a user gesture, so "start" had to be a real click.
Deterministic timing is underrated: it made the thing recordable and the code simpler.

I'm animating a whole set of these — sorting, Dijkstra, hash tables, binary trees. What algorithm should I visualize next? Drop it in the comments 👇

Dynamic Programming Finally Makes Sense — 1900 vs 16 Calculations Visualized in React

Amar Gul — Mon, 15 Jun 2026 17:04:25 +0000

Dynamic Programming has a reputation as
the hardest interview topic in CS.

The reputation disappears when you see
it visually.

The One Principle

Never calculate the same thing twice.

\`javascript
// Without DP — 1900+ calculations
function fibNaive(n) {
if (n <= 1) return n;
return fibNaive(n-1) + fibNaive(n-2); // recalculates everything
}

// With DP — 16 calculations
const memo = {};
function fibDP(n) {
if (n <= 1) return n;
if (memo[n]) return memo[n]; // instant lookup
memo[n] = fibDP(n-1) + fibDP(n-2);
return memo[n];
}
`\

The Numbers

fibNaive(15): 1946 function calls
fibDP(15): 16 unique calculations

Same answer. 1900 vs 16.

Two Properties to Identify DP

Overlapping subproblems — same smaller
problems appear multiple times. Check:
does fib(10) appear more than once?

Optimal substructure — optimal solution
builds from optimal subproblems. Check:
does fib(15) depend on optimal fib(14)?

Both true for Fibonacci. Both true for
most DP interview problems.

Watch It

What Is Next

This is Video 10 — the final algorithm
in the series. Next: AI and Machine
Learning visualized the same way.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

Every JavaScript Object is a Hash Table — Here is What is Actually Happening Inside Your Curly Braces

Amar Gul — Tue, 09 Jun 2026 20:35:29 +0000

Every time you write this:

\javascript const user = { name: "Amar", role: "Senior Dev" }; \\

A hash table is running under the hood.

What Actually Happens

When you set user.name = "Amar" — the
key "name" passes through a hash function:

\javascript function hashFunction(key) { let hash = 0; for (let i = 0; i < key.length; i++) { hash = (hash + key.charCodeAt(i)) % BUCKET_COUNT; } return hash; } // hashFunction("name") → 3 // Value stored in bucket 3 \\

Why Lookup is O(1)

When you read user.name:

Run hashFunction("name") → 3
Go directly to bucket 3
Return value

No searching. No comparing. No looping.
Direct access regardless of object size.

The Collision Problem

Two different keys can produce the same
bucket number. This is called a collision.

\javascript hashFunction("name") → 3 hashFunction("role") → 3 // same bucket! \\

JavaScript handles this through chaining
— each bucket holds a linked list of
all key-value pairs that hash to that
index.

Watch It Live

What's Next

Dynamic Programming — turning O(2ⁿ)
problems into O(n) with memoization.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

The 1959 Algorithm That Still Powers Every GPS on Earth — Visualized in React

Amar Gul — Tue, 02 Jun 2026 20:04:17 +0000

A mathematician named Edsger Dijkstra
invented this algorithm in 1959 while
thinking about the shortest route between
two cities in the Netherlands.

65 years later it runs inside Google Maps
billions of times every day.

Why It Still Works

Dijkstra solves the single-source shortest
path problem with one brilliant greedy insight:

When you process the closest unvisited node
first — its distance is permanently optimal.
No undiscovered shorter path can exist.

\javascript // Always pick closest unvisited node let u = -1; NODES.forEach((n) => { if (!visited.has(n.id) && (u === -1 || dist[n.id] < dist[u])) { u = n.id; } }); \\

Edge Relaxation

For every neighbor of the current node —
check if going through this node creates
a shorter path:

\javascript for (const { node: v, weight } of adj[u]) { if (!visited.has(v) && dist[u] + weight < dist[v]) { dist[v] = dist[u] + weight; } } \\

If yes — update. This is called relaxation.
Watch it happen in real time in the
visualization below.

The One Weakness

Negative edge weights break the greedy
assumption entirely. A negative edge
could always create a shorter path through
an already finalized node.

For negative weights — Bellman-Ford
takes over.

Watch It Live

What's Next

Hash Tables — O(1) lookup explained
visually. How JavaScript objects work
under the hood in 2 minutes.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

BFS vs DFS — Same Graph, Why Such Different Paths? Visualized in React

Amar Gul — Sat, 30 May 2026 21:35:30 +0000

BFS and DFS show up in every technical
interview. Most developers know the
names but get confused explaining
the difference.

Until you see them run on the same graph.

The Core Difference

BFS (Breadth First Search) uses a Queue.

\javascript // BFS — process level by level const queue = [startNode]; while (queue.length > 0) { const node = queue.shift(); // front visited.add(node); for (const neighbor of adj[node]) { if (!visited.has(neighbor)) { queue.push(neighbor); // back } } } \\

DFS (Depth First Search) uses a Stack
(or recursion).

\javascript // DFS — go deep first function dfs(node) { visited.add(node); for (const neighbor of adj[node]) { if (!visited.has(neighbor)) { dfs(neighbor); // recurse deep } } } \\

When to Use Each

BFS → Shortest path, level-order traversal,
GPS navigation, social network degrees

DFS → Cycle detection, topological sort,
maze solving, all possible paths

Watch It

What's Next

Dijkstra's Algorithm — shortest path in
weighted graphs. The algorithm powering
GPS navigation.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

Linked Lists Finally Simple — Why Insert is O(1) When Arrays Are O(n)Uses This Algorithm for .sort()

Amar Gul — Sat, 23 May 2026 20:44:08 +0000

Most developers understand arrays intuitively.
But Linked Lists feel abstract until you
see them visually.

The Core Problem with Arrays

When you insert in the middle of an array,
every element after the insertion point
must shift one position right.

With 1000 elements that means 999 shifts.
That's O(n) time.

How Linked Lists Solve This

A Linked List node contains two things:

The actual data value
A pointer to the next node

Insertion only updates 2 pointers:

\`javascript
// Point previous node to new node
prevNode.next = newNode;

// Point new node to next node

newNode.next = nextNode;
`\

That's it. O(1) time regardless of
list size.

The Trade Off

Fast insertion. Slow access.

Arrays: O(1) access by index
Linked Lists: O(n) access — must traverse

Choose based on your use case:

Frequent insertion/deletion → Linked List
Frequent access by index → Array

Built in React

Three operations animated:

Traverse — walks HEAD to TAIL
Insert — shows 2 pointer updates
Delete — shows pointer reconnection

\`javascript
async function insertMiddle() {
const insertPos = Math.floor(nodes.length / 2);

// Traverse to position
for (let i = 0; i <= insertPos; i++) {
setTraversing(i);
await addDelay(SPEED);
}

// Insert new node
setNodes(prev => {
const updated = [...prev];
updated.splice(insertPos, 0, newNode);
return updated;
});
}
`\

Watch It

What's Next

Binary Search Tree — self organizing
structure that achieves O(log n) for
search, insert and delete simultaneously.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

Quick Sort — Why Your Programming Language Uses This Algorithm for .sort()

Amar Gul — Sat, 23 May 2026 20:42:45 +0000

Every time you call .sort() in JavaScript,
Python, or Java — Quick Sort is running
under the hood.

Not Bubble Sort. Not Merge Sort. Quick Sort.

Why Quick Sort?

It combines two things perfectly:

O(n log n) average performance
In-place sorting — no extra memory needed

Merge Sort also achieves O(n log n) but
requires O(n) extra space. Quick Sort only
needs O(log n) stack space for recursion.

The Core Idea — The Pivot

\`javascript
function partition(arr, low, high) {
const pivot = arr[high];
let i = low - 1;

for (let j = low; j < high; j++) {
if (arr[j] <= pivot) {
i++;
[arr[i], arr[j]] = [arr[j], arr[i]];
}
}
[arr[i + 1], arr[high]] = [arr[high], arr[i + 1]];
return i + 1;
}
`\

Pick a pivot. Everything smaller goes left.
Everything larger goes right.
The pivot is now in its permanent position.

The One Weakness

Worst case is O(n²) — when pivot is always
the smallest or largest element.

Modern implementations use randomized pivot
selection to avoid this trap.

Watch It

What's Next

Linked Lists — a completely different
approach to storing data in memory.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

Merge Sort vs Bubble Sort — Why 800 Comparisons Beats 147 Every Time

Amar Gul — Sat, 16 May 2026 19:00:50 +0000

Most developers know Merge Sort is faster
than Bubble Sort. But watching it happen
makes the difference visceral.

The Numbers

Bubble Sort: 800+ comparisons
Merge Sort: 147 comparisons
Same 30 elements. Same result.

Why Such a Difference?

Bubble Sort compares adjacent elements
and moves them one step at a time —
O(n²) in worst case.

Merge Sort divides the array completely
down to single elements, then merges
them back in sorted order — O(n log n)
guaranteed every single time.

The Key Code

The entire algorithm is built on one
recursive insight:

\javascript function mergeSort(arr, left, right) { if (left >= right) return; const mid = Math.floor((left + right) / 2); mergeSort(arr, left, mid); mergeSort(arr, mid + 1, right); merge(arr, left, mid, right); } \\

A single element is already sorted by
definition. Everything else is just
merging sorted groups together.

Built in React — Zero Libraries

Animation state managed entirely with
useState and useRef. No external
animation libraries.

Color coding:

Purple = unsorted
Gold = currently merging
Red = comparing
Cyan = fully sorted

Watch It

What's Next

Quick Sort — the algorithm that actually
powers sorting in most programming
languages. Spoiler: it's faster than
Merge Sort in practice despite worse
worst-case complexity.

Subscribe to AlgoCanvas:
👉 youtube.com/@AlgoCanvas

Binary Search vs Linear Search — Visualized in React with No Libraries

Amar Gul — Tue, 12 May 2026 16:45:09 +0000

As a Senior React developer I wanted to
show exactly WHY binary search exists —
not just explain it with words.

So I built a side by side comparison
showing both algorithms running on the
same array searching for the same target.

The Visual Difference

Linear search checks every element from
left to right. Predictable but slow.

Binary search goes straight to the middle.
Higher or lower? Eliminate half. Repeat.

Tech Stack

React functional components
useState for animation state
useRef for timeout management
Zero external animation libraries

The Key Code

Two separate animation pipelines running
sequentially — linear first, then binary:

\`javascript
// Linear search steps
for (let i = 0; i < array.length; i++) {
steps.push({ checking: i });
if (array[i] === target) break;
}

// Binary search steps

while (low <= high) {
const mid = Math.floor((low + high) / 2);
steps.push({ middle: mid, eliminated });
if (array[mid] === target) break;
else if (array[mid] < target) low = mid + 1;
else high = mid - 1;
}
`\

The Result

What's Next

Building visualizations for:

Merge Sort
Quick Sort
Dijkstra's Algorithm
Binary Search Trees
Hash Tables

Subscribe to AlgoCanvas on YouTube:
👉 youtube.com/@AlgoCanvas

Feedback welcome — drop a comment below!

How I Built a Bubble Sort Visualizer in React — No Animation Libraries

Amar Gul — Sat, 09 May 2026 18:08:50 +0000

As a Senior React developer I've built dozens
of complex applications — but I wanted to create
something that actually helps people understand
computer science fundamentals visually.

So I built AlgoCanvas — a series of algorithm
visualizations built purely in React.

Why I Built This

Most algorithm explanations use static diagrams
or walls of code. Neither actually shows you
what the algorithm is doing at each step.

I wanted to change that. Watch it work — and
it clicks instantly.

The Tech Stack

React functional components
useState for animation state
useRef for timeout management
CSS-in-JS inline styles
Zero external animation libraries

How the Animation Works

The key insight is building all animation steps
upfront, then replaying them with setTimeout:

function bubbleSort() {
  const arr = [...array];
  const steps = [];

  for (let i = 0; i < arr.length - 1; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      steps.push({ 
        arr: [...arr], 
        comparing: [j, j + 1] 
      });
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
        steps.push({ 
          arr: [...arr], 
          comparing: [j, j + 1] 
        });
      }
    }
  }
  return steps;
}

Then replay each step with a delay:

steps.forEach((step, index) => {
  setTimeout(() => {
    setArray(step.arr);
    setComparing(step.comparing);
  }, index * 120);
});

Color Coding System

🟣 Purple — unsorted elements
🔴 Red — currently being compared
🩵 Cyan — fully sorted and done

This makes it immediately obvious what the
algorithm is doing at every single step.

The Result

What's Next

I'm building visualizations for:

Binary Search
Merge Sort
Quick Sort
Dijkstra's Algorithm
Binary Search Trees
Hash Tables

Subscribe to AlgoCanvas on YouTube if you
want to follow along:
👉 youtube.com/@AlgoCanvas

Feedback Welcome

Would love to hear from other React developers:

Better patterns for animation state?
Which algorithm should I visualize next?
Any performance improvements?

Drop a comment below!

DEV Community: Amar Gul

Backpropagation Is Just Dynamic Programming (I Animated It to Prove It)

What you're actually seeing

The stack

Three things that were trickier than expected

1. My animated particle was blinking on every frame

2. The sound wouldn't play

3. Syncing a fixed-timer animation to a recorded voiceover

What I learned

Watch it

I Visualized Why AI Models Fail to Train — It's One Number

What you're actually seeing

The stack

Three things that were trickier than expected

1. The SVG ball stuttered until I stopped animating cx/cy

2. Recording needs identical-length runs — so I drift-corrected the clock

3. A stale closure made my "auto" sequence ignore the learning rate

What I learned

Watch / try it

I Built a Neural Network You Can Watch Train — Forward Pass, Loss, and Backprop, Animated

What you're actually seeing

The stack

Three things that were trickier than expected

1. Animate particles with CSS transforms, not SVG attributes

2. Backprop has to flow backward

3. Make the network show it's learning

Bonus: deterministic timing (so I could record it)

What I learned

Dynamic Programming Finally Makes Sense — 1900 vs 16 Calculations Visualized in React

The One Principle

The Numbers

Two Properties to Identify DP

Watch It

What Is Next

Every JavaScript Object is a Hash Table — Here is What is Actually Happening Inside Your Curly Braces

What Actually Happens

Why Lookup is O(1)

The Collision Problem

Watch It Live

What's Next

The 1959 Algorithm That Still Powers Every GPS on Earth — Visualized in React

Why It Still Works

Edge Relaxation

The One Weakness

Watch It Live

What's Next

BFS vs DFS — Same Graph, Why Such Different Paths? Visualized in React

The Core Difference

When to Use Each

Watch It

What's Next

Linked Lists Finally Simple — Why Insert is O(1) When Arrays Are O(n)Uses This Algorithm for .sort()

The Core Problem with Arrays

How Linked Lists Solve This

The Trade Off

Built in React

Watch It

What's Next

Quick Sort — Why Your Programming Language Uses This Algorithm for .sort()

Why Quick Sort?

The Core Idea — The Pivot

The One Weakness

Watch It

What's Next

Merge Sort vs Bubble Sort — Why 800 Comparisons Beats 147 Every Time

The Numbers

Why Such a Difference?

The Key Code

Built in React — Zero Libraries

Watch It

What's Next

Binary Search vs Linear Search — Visualized in React with No Libraries

The Visual Difference

Tech Stack

The Key Code

The Result

What's Next

How I Built a Bubble Sort Visualizer in React — No Animation Libraries

Why I Built This

The Tech Stack

1. The SVG ball stuttered until I stopped animating `cx`/`cy`