The event loop: one thread, ordered phases

A developer writes setTimeout(fn, 0) next to setImmediate(fn) next to Promise.resolve().then(fn), expecting them to fire in source order. They do not. The promise runs first, then — depending on where the code sits — either the timer or the immediate. This is not a bug or a race; it is the event loop’s published schedule. The loop is not a black box that “runs async stuff eventually.” It is a strict, ordered machine, and once you can see its phases, async timing stops being folklore.

The loop is a sequence of phases

The single thread from the last lesson does not run callbacks in arrival order. It cycles through a fixed sequence of phases (in libuv, Node’s loop engine), and each phase has its own queue of callbacks to drain before moving on. The ones that matter day to day:

• Timers — callbacks whose setTimeout/setInterval delay has elapsed.
• Poll — the heart: retrieve new I/O events and run their callbacks (an HTTP request arrived, a file read finished). If nothing is pending, the loop blocks here waiting on epoll/kqueue — this is where idle time is spent.
• Check — callbacks scheduled with setImmediate, run right after poll.
• Close — close-event callbacks (socket.on('close')).

One full trip through the phases is a tick of the loop. Within a phase, callbacks run one at a time, to completion — there is no preemption.

Macrotasks vs microtasks

Two of those words hide the whole timing model. The phase queues hold macrotasks: a timer callback, an I/O callback, a setImmediate. Separate from them are two microtask queues with higher priority:

• process.nextTick callbacks (Node-specific), drained first.
• Promise reactions (.then/await continuations).

The rule: after every single callback finishes, the loop fully drains the microtask queues before running the next callback or advancing a phase. That is why Promise.resolve().then(fn) beats a setTimeout(fn, 0) — the promise reaction is a microtask that runs at the next drain, while the timer waits for the timers phase on a later tick.

setTimeout(0) vs setImmediate

These two are the classic confusion. setImmediate always runs in the check phase, right after poll; setTimeout(fn, 0) is clamped to a ~1 ms minimum and runs in the timers phase. Inside an I/O callback (i.e., already in or just past poll), setImmediate reliably fires before the next timers phase, so it wins. At the top level of a script, the order is not guaranteed — it depends on how much time the loop spent starting up. The senior takeaway is not the trivia but the model: “immediately after I/O” and “after the timer delay” are different phases, not the same queue.

Cooperative, not parallel

Because one thread runs each callback to completion with no preemption, the event loop’s concurrency is cooperative: every callback must voluntarily yield — by finishing, or by hitting an await that hands control back — for any other callback to run. Two requests are never executing JavaScript at the same instant; they interleave at yield points. This is the whole strength (no locks, no data races on shared state within a tick) and the whole weakness (one callback that never yields freezes everything), which the next lesson makes concrete.