The event loop: tasks, microtasks, and why a then beats setTimeout(0)

JavaScript runs your code on one thread. While a function is running, nothing else in that program runs — no timer fires, no click handler, no promise callback. The event loop is what decides what runs next once the current code finishes.

Two queues

• Tasks (also called macrotasks): a timer firing, an I/O callback, a click, a message. The loop takes one task, runs it to completion, then moves on.
• Microtasks: promise callbacks (then, catch, finally), the continuation of an async function after an await, and anything passed to queueMicrotask. After every task — and after the initial script — the loop runs every microtask in the queue, including any queued by those microtasks, before it takes the next task.

So a promise callback always runs before a setTimeout(fn, 0) scheduled at the same moment: the timer is a new task, and the microtask queue drains before the loop gets to it. Node adds one more queue, process.nextTick: when a callback such as a timer finishes, Node runs the nextTick queue first and then the promise microtasks. Browsers render between tasks, never in the middle of the microtask queue.

1export function run() {2  return new Promise((resolve) => {3    const log = [];4    setTimeout(() => {5      log.push("sync: start");6      setTimeout(() => {7        log.push("task: setTimeout 0");8        resolve(log);9      }, 0);10      Promise.resolve().then(() => log.push("microtask: then"));11      queueMicrotask(() => log.push("microtask: queueMicrotask"));12      process.nextTick(() => log.push("nextTick"));13      log.push("sync: end");14    }, 0);15  });16}

The example schedules everything from inside a timer callback, an ordinary task, which is where most real code runs.

Where code after await runs

An async function runs synchronously up to its first await. At that point it returns a pending promise to its caller, and the rest of the function is queued as a microtask for when the awaited value settles — even await null, which has nothing to wait for, gives up control until the current synchronous code is done.

1export function run() {2  return new Promise((resolve) => {3    const log = [];4    async function load() {5      log.push("load: before await");6      await null;7      log.push("load: after await");8    }9    setTimeout(() => {10      log.push("caller: start");11      load();12      Promise.resolve().then(() => log.push("caller: then"));13      log.push("caller: end");14      setTimeout(() => resolve(log), 0);15    }, 0);16  });17}

Microtasks can starve everything else

Because the queue is drained completely, a microtask that keeps queueing another microtask never lets the loop reach the next task. Timers wait, I/O waits, and in a browser the page cannot repaint. A long loop of synchronous work has the same effect. Splitting work into setTimeout(..., 0) chunks yields to the loop between chunks; splitting it into microtasks does not. The exercise does the first.

1export function run() {2  return new Promise((resolve) => {3    let count = 0;4    setTimeout(() => resolve(`timer ran after ${count} microtasks`), 0);5    function spin() {6      count++;7      if (count < 10000) queueMicrotask(spin);8    }9    queueMicrotask(spin);10  });11}

Common mistakes

• Using setTimeout(fn, 0) to mean "right after this". Promise callbacks and awaits queued at the same time all run first.
• Assuming await blocks the program. It suspends only its own function; the caller continues straight away (the second example).
• "Yielding" with await Promise.resolve() inside a long loop. It queues a microtask, so timers and rendering still wait for the whole loop.
• Expecting setTimeout(fn, 100) to run at exactly 100 ms. The delay is a request, not a schedule: the callback runs once the timer has expired and the thread is free, which can be much later.

What interviewers ask

• Predict the output of a snippet mixing console.log, setTimeout(0) and Promise.resolve().then. — Synchronous logs first, then the promise callbacks, then the timeout.
• What is the difference between a microtask and a macrotask? — One task runs per loop turn; after it, the whole microtask queue is drained, so microtasks always run before the next task.
• How would you keep a long computation from freezing the page? — Split it into chunks scheduled as tasks (setTimeout, a MessageChannel), or move it to a Web Worker; microtasks do not help.