Microtasks vs macrotasks: ordering

Two queues, two cadences

The previous lesson fixed who owns what: the host owns the loop and the macrotask queues; the engine owns the microtask queue. This lesson makes the ordering precise, because the two queues drain on completely different cadences.

• Macrotasks (the spec calls them simply tasks) — exactly one runs per loop turn. Sources: setTimeout/setInterval callbacks, I/O completion callbacks, MessageChannel/postMessage messages, fired DOM events, parsed HTML chunks. After running one, the loop does not immediately run the next macrotask.
• Microtasks — the entire queue is drained after each macrotask, and again whenever the JavaScript call stack empties. Sources: Promise.then/.catch/.finally reactions, queueMicrotask jobs, await continuations, MutationObserver callbacks.

The asymmetry is the whole point. Macrotasks are rationed — one per turn — so the loop can render and handle input between them. Microtasks are exhaustive — drained to empty — so a coherent unit of async follow-up (a promise chain) completes atomically before anything else happens. The browser overview (browser/01-event-loop/04-microtask-starvation) shows the failure mode at runtime depth; here we tie it to the queue mechanics.

The canonical ordering example

console.log("1: sync start");

setTimeout(() => console.log("4: macrotask (setTimeout)"), 0);

Promise.resolve()
  .then(() => console.log("3a: microtask one"))
  .then(() => console.log("3b: microtask two"));

queueMicrotask(() => console.log("3c: queueMicrotask"));

console.log("2: sync end");
// Output: 1 → 2 → 3a → 3c → 3b → 4

Walk it precisely. The synchronous script is the current macrotask. It runs to completion first: 1, then 2. Along the way it scheduled a macrotask (the setTimeout) and microtasks (the .then and the queueMicrotask). When the script’s stack empties, the engine drains the microtask queue in FIFO order: the first .then (3a) and the queueMicrotask (3c) were enqueued during the sync run, so they go first; 3a’s handler returns, which now settles the chained promise and enqueues 3b — appended to the same drain — so 3b runs before the drain ends. Only when the microtask queue is finally empty does the host pick the next macrotask: 4.

Why a microtask that enqueues a microtask is dangerous

Because the microtask checkpoint drains to empty, a microtask that enqueues another microtask before returning is processed in the same drain, not the next one. There is no “next turn” boundary to escape to. Repeat it and the queue never empties:

function spin() {
  Promise.resolve().then(spin); // re-arms inside the same checkpoint
}
spin(); // freezes: the checkpoint never completes, the engine never returns

This is microtask starvation. The host never gets the thread back (the engine is stuck inside PerformMicrotaskCheckpoint from lesson 1), so no macrotask runs, no frame paints, no input is handled. Contrast with a macrotask self-loop — setTimeout(spin, 0) — which re-arms on a host queue, so the engine returns between iterations and the page stays responsive (just busy). The cure for starvation is always to insert a macrotask-level yield into the chain.

Node specifics: process.nextTick and per-phase draining

When you’re reading a Node codebase and process.nextTick fires before your Promise.resolve().then, it’s not a bug or a quirk — it’s an intentional second pre-promise queue. Node complicates the picture with two extra rules. First, process.nextTick callbacks run in a queue that is separate from and drained before the Promise microtask queue. So in Node, process.nextTick always beats Promise.resolve().then. Second, Node’s loop runs in phases (timers → pending callbacks → poll → check → close), and historically Node drained microtasks between phases rather than after every single callback — though since Node 11 it drains microtasks after each individual macrotask callback, bringing it closer to browser semantics.

// In Node:
setTimeout(() => console.log("timeout"), 0);     // timers phase (macrotask)
setImmediate(() => console.log("immediate"));     // check phase (macrotask)
Promise.resolve().then(() => console.log("promise")); // microtask
process.nextTick(() => console.log("nextTick"));  // nextTick queue — first

// Order: nextTick → promise → (timeout|immediate, order between these
// two is not guaranteed from the main module)

The practical senior takeaway: never rely on setTimeout vs setImmediate ordering from the top level, but do rely on process.nextTick running before promise microtasks. And beware: process.nextTick has the same starvation hazard as a microtask loop — a recursive nextTick starves the phase loop just as a recursive .then starves the browser.