Event Loop Visualizer — Free HTML CSS JS Snippet

"Why does the order come out 1, 4, 3, 2?" is the single most-asked JavaScript interview question, and almost every answer to it is memorized rather than understood. This snippet exists to make the answer visible instead of memorized: three animated lanes — Call Stack, Web APIs / Task Queue, and Microtask Queue — plus a code panel and a console panel, all wired to a small event-driven playback engine that steps through real execution semantics in the right order, one DOM update at a time.

Why the algorithm is data, not a real interpreter

This snippet does not parse or execute JavaScript. Each of the three presets is authored as a plain array of step objects ({ kind: 'log' | 'macro' | 'micro', line, text, task }) that describes, in order, exactly what the real V8 engine would do for that snippet. That is a deliberate simplification: building an actual JS interpreter in a demo widget would bury the concept it's trying to teach under parser code. Instead the "truth" of the ordering is encoded once, correctly, by a human who understands the event loop, and the animation engine's only job is to play that truth back convincingly — the same event-precomputation pattern used by the recursion tree visualizer and sorting algorithm visualizer elsewhere in this library.

Two queues, one algorithm: drain-microtasks-first

The entire event loop is two functions. drainMicrotasks() is a while (microQueue.length) loop that keeps shifting tasks off the front of microQueue and running them until the queue is completely empty — not just once, but until nothing is left, including microtasks that get scheduled *during* the drain (see the nested example below). runEventLoop() calls drainMicrotasks() first, then enters a while (macroQueue.length) loop that shifts exactly one macrotask, runs it, and immediately calls drainMicrotasks() again before considering a second macrotask. That ordering — drain microtasks completely, then take one macrotask, then drain microtasks completely again — is not a simplification for this demo; it is the literal specification of how the HTML event loop processes its job queues, and it is the exact mechanism that explains why Promise.resolve().then() always wins a race against setTimeout(fn, 0) no matter which one was written first in the source.

Scheduling versus running are visually two different moments

A common misreading of the phrase "setTimeout schedules a macrotask" is to think the callback runs immediately when setTimeout() is *called*. This snippet keeps those two moments visually distinct: calling setTimeout(fn, 0) is itself a synchronous operation, so it pushes a real elv-chip-stack entry onto the Call Stack lane, sits there briefly, and pops off — that's the runSchedule() function doing exactly what a real synchronous function call does. Only *after* that stack frame pops does the scheduled callback exist purely as an amber chip sitting in the Task Queue lane, waiting. The callback itself does not run, and does not get its own stack frame, until the event loop specifically pulls it off that queue later. The same distinction applies to .then(): calling .then() is synchronous and pushes/pops the stack immediately, while the *callback passed to* .then() only runs later, during a microtask drain.

The nested-microtask preset proves the queue is live, not a snapshot

The third preset (Nested microtask escapes just in time) is the one that actually separates "I memorized 1-4-3-2" from "I understand the drain loop." Its microtask callback logs 'promise 1' and then, inside that same callback, calls Promise.resolve().then() again — scheduling a *second* microtask while the first one is still executing. In runTaskFromQueue(), this is modeled with an optional task.spawnsMicro field: after logging the task's own message, if spawnsMicro is set, a new task object is pushed onto the live microQueue array and a new chip animates into the Microtask Queue lane, mid-drain. Because drainMicrotasks()'s while loop re-checks microQueue.length on every iteration rather than iterating over a fixed-length snapshot taken at the start, that freshly-spawned nested microtask still gets drained *before* the pending setTimeout macrotask runs — visually proving that microtasks can keep cutting in line indefinitely, which is also the real-world mechanism behind infamous "microtask starvation" bugs where a chain of self-scheduling promises can delay setTimeout and rendering indefinitely.

Chip lifecycle: shared DOM primitives across all three lanes

All three lanes reuse the same small set of primitives: pushStack()/popStack() for the Call Stack (a column-reverse flex list so the newest entry visually sits on top, exactly like the linked list visualizer's node styling conventions), and addQueueChip()/removeQueueChip() for the two queue lanes (a wrapping flex row, oldest chip first, since queues are FIFO). Every chip animates in with a scale pop-in keyframe and animates out with a fade-and-shrink before being removed from the DOM, so nothing ever just snaps into or out of existence — every state change the algorithm makes has a matching, readable animation frame the user can actually watch happen.

The status line narrates the algorithm's own reasoning

Rather than leaving the viewer to infer why a chip is moving, setStatus() is called at every phase transition with the actual rule being applied in plain language — "Call stack is empty, draining the microtask queue completely before anything else runs," then later "Microtask queue is empty, the event loop pulls exactly one macrotask now." This turns the animation into a running commentary on the specification itself, so a viewer walks away able to state the drain-microtasks-first rule in their own words, not just recognize the final printed order.