Microtasks vs Macrotasks

A macrotask is a chunk of work the event loop takes from the task queue, one at a time. A microtask is a piece of work that goes into a separate queue, and that queue is drained completely before the loop takes the next macrotask.

The difference is about priority and about how much of the queue gets processed at once. The microtask queue is emptied fully, and it includes any microtasks those microtasks queue. The task queue is taken one entry at a time, and the microtask queue is drained after each one.

In practice the split is this. Promise reactions, the queueMicrotask function and the MutationObserver callbacks are microtasks. Timers, network completions, user events and the initial script execution are macrotasks.

The consequence is the ordering people find surprising. A promise callback always runs before a timer callback, even when the timer was scheduled first and has a delay of zero. And a promise callback queued from inside a timer callback runs before the next timer, because the microtask queue is drained after every task.

One more distinction that matters for design. Because the microtask queue is drained completely, a chain of promise callbacks can starve the event loop. If each one queues another, timers and input handling never run and the page appears frozen. Yielding to a macrotask, by scheduling a timer with a zero delay, gives the runtime a chance to render and to handle input again.

This is the classic ordering example. Read the output carefully, because two of the lines are not where most people expect them.

console.log("A - sync start");

setTimeout(() => {
  console.log("F - timeout");
  Promise.resolve().then(() => console.log("G - microtask queued inside a timeout"));
}, 0);

Promise.resolve()
  .then(() => console.log("B - microtask 1"))
  .then(() => console.log("C - microtask 2"));

queueMicrotask(() => console.log("D - queueMicrotask"));

console.log("H - sync end");

The output is A, H, B, D, C, F, G. The synchronous lines come first because nothing has yielded yet. Then the microtask queue drains. The first promise callback runs, and because it is a chain, the second callback is not queued until the first has finished, which puts it behind the queueMicrotask callback. Then the timer task runs, and the microtask it queues runs immediately afterwards, before the loop would take any other task.

The subtle point is the position of C. Many people expect the chained callback to follow B immediately, and it does not. A chained then handler is only scheduled when the promise it is attached to settles, which happens after the first callback returns, so it joins the back of the microtask queue rather than the front.

A related detail about timers. The delay is a minimum, so a timer scheduled for zero milliseconds still waits until the current task and the microtask queue are finished. That is why the timer line always comes after every microtask that was queued before it, even though the timer was set up first.