Macrotask Queue (Task Queue)
The macrotask queue (also called the task queue) holds callbacks from setTimeout, setInterval, setImmediate (Node), I/O events, and UI events. The event loop picks one macrotask per loop iteration.
Macrotasks are the regular waiting room at the DMV — only one person is called per round, and those VIP microtask folks always cut in between.
Only ONE macrotask is dequeued per event loop iteration, after which the entire microtask queue is drained before the next macrotask runs. setTimeout(fn, 0) doesn't mean 'run immediately' — it means 'enqueue a macrotask no sooner than 0ms'. Browsers clamp minimum delay to ~4ms for nested timers after the 5th level. There are actually multiple macrotask queues with different priorities (e.g., user interaction queues are prioritized over timer queues in browsers).
The HTML spec defines 'task sources' — each source has its own queue, and the browser's rendering pipeline decides which queue to service next based on priority. The 'scheduling' proposal (scheduler.postTask) exposes this priority system explicitly. In Node.js, libuv's event loop has distinct phases: timers → pending callbacks → idle/prepare → poll (I/O) → check (setImmediate) → close callbacks. setImmediate runs in the 'check' phase after I/O, making it more predictable than setTimeout(fn, 0) inside I/O callbacks.
The event loop picks exactly one macrotask per iteration, then drains all microtasks before the next one. setTimeout/setInterval, I/O callbacks, and UI events are all macrotasks. The practical implication: you can split a long computation into setTimeout(fn, 0) chunks to yield to the UI, but Promise chains between those chunks will all resolve before the next chunk runs.
setTimeout(fn, 0) is not guaranteed to fire in 0ms — browsers enforce a minimum delay (~4ms for nested timers) and the callback only fires when the call stack is empty AND no microtasks are pending. Under heavy microtask load, a 0ms timer can wait significantly longer.