The Runtime Theory

The Event Loop Tick

One event-loop tick: macrotasks, microtask draining, requestAnimationFrame, rendering, and why promises beat timers.

The Runtime Theory Team07 stages

trace / request.md

PICK THE NEXTMACROTASKTASK RUNS TOCOMPLETIONMICROTASKSENQUEUEDDRAIN THEMICROTASK QUEUENEXT-FRAMECALLBACKSRENDER AND PAINTBACK TOMACROTASKS

readyThe loop takes the oldest task from the macrotask queue: setTimeout or setInterval callbacks, I/O events, and user interaction callbacks all land here.

An event-loop tick is a fixed order of operations: one macrotask, every microtask it enqueued, then — in browsers — a render pass. This diagram shows one full tick: the loop dequeues a macrotask, runs it to completion on a fresh stack, drains the microtask queue until it is empty, runs requestAnimationFrame callbacks, paints, and returns to the queue. The ordering is the entire contract. Promises resolve before timers because microtasks drain before the next macrotask is even dequeued. A long microtask chain can starve rendering, and a long macrotask blocks everything — the diagram makes both visible with per-stage counters. It is a loop, but never a fair one: microtasks always jump the queue. The done state shows the render pass complete and the loop ready for its next tick.