DEV Community

Cover image for AlgoVerse: watching algorithms think at 60fps in the browser
Divyakush Punjabi
Divyakush Punjabi

Posted on

AlgoVerse: watching algorithms think at 60fps in the browser

Algorithms you can watch think

A sorting algorithm is a set of decisions unfolding over time. A textbook flattens that into pseudocode and a Big-O label, and something is lost — you can memorize that quicksort is O(n log n) on average without ever seeing why it degrades on a sorted array. AlgoVerse is my attempt to put the time dimension back: a client-side platform where you watch data structures and algorithms actually run, step by step, at 60fps.

There's a live demo, and the whole thing runs in your browser with no backend.

AlgoVerse Sorting Laboratory — step-through algorithm visualization

The stack, and why this one

AlgoVerse is built on React 19, TypeScript 5.8, Vite 6, Three.js R183, and Tailwind 4 — deliberately current. Two constraints shaped the choices:

  • Everything is client-side. No server means no round-trips, no cold starts, and a project anyone can fork and deploy statically. Every visualization computes in the browser.
  • Animation is the product, so it has to be smooth. Sixty frames per second isn't a vanity metric here; a stuttering sort visualization actively teaches the wrong intuition about where the work happens. Three.js handles the WebGL hero scene; the algorithm views use tuned canvas and SVG rendering.

The modules that matter

The platform is organized into interactive labs. A few are worth calling out because the engineering behind them is more than "draw some bars."

Sorting Laboratory. Step-through visualization with real-time telemetry — live counts of comparisons and swaps as the algorithm runs. You can feed custom datasets, scrub the speed from 0.25× to 4×, and push array sizes up to 200 elements. Watching comparison and swap counters tick in real time is where the abstract cost of an algorithm becomes concrete.

Comparison Arena. A race mode: pit two sorting algorithms against the same dataset and watch them compete side by side, with live metrics and a winner. This is the module that makes "average case" stop being a phrase and start being a thing you've seen happen — run bubble sort against quicksort on 200 elements and the gap is visceral.

Complexity Lab. Interactive growth-curve charting rendered as SVG from computed data points. Toggle between best/average/worst case, switch between time and space complexity, and drag the input size n up to 1000 to watch the curves diverge. It turns the complexity table you memorized into something you can interrogate.

AlgoVerse data-structure visualizations

Tree Explorer. Canvas-rendered BST, AVL, Min-Heap, and Max-Heap structures with animated insertions. The AVL view does the thing textbooks gesture at and rarely show cleanly: automatic rotations — LL, RR, LR, and RL — animated as they happen, plus step-by-step inorder, preorder, and postorder traversals. Seeing an AVL tree rebalance itself mid-insertion is worth more than a page of rotation diagrams.

Graph Visualizer. Click to place nodes, add weighted edges, and run BFS, DFS, or Dijkstra's shortest path with the traversal highlighted as it explores.

Algorithm Recommender. A constraint-based advisory engine: give it your system parameters — memory budget, latency target, data volume — and it recommends an algorithm with the architectural rationale for why.

What was actually hard

The honest engineering challenge in a project like this isn't the algorithms — those are well-understood. It's keeping the visualization decoupled from the computation while staying at 60fps.

If you interleave "compute the next step" with "render the current frame" naïvely, you get one of two failure modes: the animation blocks while the algorithm thinks, or the algorithm races ahead of what the eye can follow. The architecture separates the two — the algorithm produces a stream of discrete steps, and the renderer plays them back at a controllable rate. That separation is what makes the speed slider (0.25×–4×) possible at all, and it's what keeps large inputs from freezing the UI.

The second challenge is visual consistency across wildly different structures — a sorting array, an AVL tree, a weighted graph, an SVG growth curve — all sharing one coherent design language instead of looking like six different apps stapled together.

Why build it at all

Educational tooling has a reputation for looking like it was built in 2009, and that reputation is mostly earned. I wanted to prove that learning tools can have the same production polish as any consumer app — glassmorphism, real 3D, genuinely smooth motion — without the polish being the point. The point is comprehension; the polish just removes the friction between the learner and the idea.

The full module list, architecture, and design system are in the repository (MIT licensed), and there's a live demo you can open right now and race two algorithms against each other.


www.divyakush.com · GitHub · LinkedIn

Top comments (0)