Recursion Tree Visualizer — Free HTML CSS JS Snippet

Recursion is usually explained with a diagram of a tree that's already fully drawn, which skips the part that actually confuses people: the tree is built by a program that calls itself, descending and returning in a very specific order. This snippet makes that order visible by animating naive recursive Fibonacci as it actually executes — nodes appear as calls happen, a call-stack panel pushes and pops in real time next to the tree, and a memoize toggle lets you watch exponential blowup collapse into linear work.

Event pre-computation, same architecture as the other visualizers

buildEvents(n, memoize) runs the actual recursive fib() function to completion before any animation happens, but instead of just returning a number it pushes a timeline of events as it goes: call when a function invocation begins, memo-hit when a cached result short-circuits a would-be call, combine when a node's two children's results are summed, and return when a call finishes and should pop off the stack. This is the same separation-of-concerns pattern used by the sorting and pathfinding visualizers in this library — the recursive algorithm never touches the DOM or timing, it only narrates itself into a flat event list that gets replayed afterward.

Why naive Fibonacci is O(2^n): the branching made visible

Naive recursive fib(k) calls fib(k-1) and fib(k-2), and neither call knows anything the other computed. fib(5) calls fib(4) and fib(3); fib(4) calls fib(3) and fib(2) — notice fib(3) gets computed twice, entirely from scratch, with its own full sub-tree of calls each time. Every node in the tree spawns two more nodes until the base case (k <= 1) is hit, so the total call count roughly doubles with each increment of n — the textbook definition of O(2^n) exponential growth. Run this visualizer at n = 10 with Memoize off and watch the Calls counter: it climbs into the hundreds, and the tree visibly balloons sideways because fib(3), fib(2), and fib(1) are each independently re-derived dozens of times.

How the memoize toggle collapses the tree to O(n)

When the Memoize checkbox is on, buildEvents keeps a plain memo object keyed by the Fibonacci input k. Before making a real recursive call, fib() checks memo[k] !== undefined; if the value is already cached, it pushes a memo-hit event instead of a full call event and returns immediately without recursing further. On screen, memo-hit nodes render grey and semi-transparent, connected to their parent but visually distinct from an actively-computed orange node — you can watch entire sub-trees that would normally re-expand get reduced to a single dimmed leaf. Because every distinct k value from 0 to n is computed at most once when memoized, the total call count grows linearly with n instead of exponentially — the Calls and Skipped (memo) counters made this concrete: run fib(10) twice, once with memoize off and once on, and compare the final Calls numbers directly.

The call stack panel: pushing and popping in sync with recursion

The .stack-list panel uses flex-direction: column-reverse so the most recently pushed call visually sits on top, mimicking how a real call stack grows upward. Every call event appends a new .stack-item div labeled fib(k) with a small pushIn keyframe animation; every matching return event removes the most recently pushed still-present item. Because JavaScript's own function call stack is what's driving buildEvents's recursion in the first place, the push/pop order in this panel is not a simulation of a call stack, it is a direct visualization of the real one — the depth-first descent (call, call, call, base case, return, return) plays out in the exact order V8 itself would execute it.

Tree layout without a charting library

Node positions are computed with plain arithmetic in nodePos(x, depth): vertical position is depth * 56 pixels, and horizontal position starts each recursive call at its parent's x offset by a spread value that shrinks as depth increases (Math.max(1.6, 5 - depth * 0.6)), so left and right children fan out proportionally to how many levels of the tree remain — deep nodes cluster tightly, shallow nodes spread wide, which keeps a tree of a few hundred nodes from overlapping. Edges are drawn as SVG <line> elements appended to a plain <svg> overlay positioned absolutely over the node container, connecting each new node to its already-positioned parent the instant the child call event fires.