The Event Loop and Microtasks

Run this and predict the order the four lines print, before reading on.

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');

The order is 1, 4, 3, 2 — not 1, 2, 3, 4, and not 1, 4, 2, 3 either. setTimeout with a delay of zero still finishes dead last, behind a promise callback that was scheduled after it.

JavaScript runs on one thread — it can only do one thing at a time — yet a page fetches data, runs timers, and responds to clicks without ever fully stopping. The event loop is the mechanism that decides what runs next, and getting that four-line puzzle right comes down to exactly one rule, which the rest of this article unpacks.

The restaurant analogy

Picture a restaurant with exactly one chef.

• The chef cooks one dish at a time, start to finish. That's the call stack.
• Orders waiting to be cooked sit in a queue on the pass. That's the task queue.
• The oven, the timer, and the delivery driver all work on their own. Those are browser APIs — not the chef, and not part of JavaScript.
• Between dishes, the chef always glances at a small priority slip holder first: corrections to the dish just served. That's the microtask queue.

The chef never abandons a dish halfway. If one dish takes twenty minutes of active work, every other order waits. That's what "blocking" means.

Where the analogy breaks: a human chef, even a disciplined one, would eventually get tired of the priority slips and serve the next full order anyway. The event loop has no such judgment call — it drains the microtask queue completely, no matter how many new slips arrive while it's looking, before it will ever glance at the task queue. That's not a minor detail. It's exactly why a microtask that keeps generating more microtasks can freeze a page forever, which the starvation trap below covers directly.

The moving parts

     ┌──────────────┐
     │  Call stack  │  ← one chef, one dish at a time
     └──────▲───────┘
            │  event loop puts the next callback here
            │  (only when the stack is empty)
   ┌────────┴──────────────────────────┐
   │                                   │
┌──┴───────────────┐        ┌──────────┴────────┐
│ Microtask queue  │        │    Task queue     │
│ promises,        │  ALL   │ setTimeout,       │
│ queueMicrotask,  │ before │ events, I/O,      │
│ MutationObserver │  ANY   │ setInterval       │
└──────────────────┘        └───────────────────┘
        ▲                            ▲
        └──── Web APIs / Node APIs ──┘
              timers, fetch, DOM events

The rule the whole article rests on: when the call stack empties, drain the entire microtask queue. Only then take one task from the task queue.

Reading the order

console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

Walking through it:

1. "1" runs immediately — synchronous code goes straight onto the stack.
2. setTimeout hands its callback to the browser's timer. It is not on the stack, and it goes to the task queue once the timer fires.
3. .then schedules a microtask — it goes to the microtask queue, not the task queue.
4. "4" runs immediately, same as step 1.
5. The stack is now empty. The event loop drains microtasks first → "3".
6. Only now does a task run → "2".

setTimeout(fn, 0) does not mean "run now." It means "run after the current work and all pending microtasks."

Why microtasks come first

A promise represents a value that has already been decided. Callbacks reacting to that decision should not be delayed by unrelated work such as a timer that happened to be scheduled earlier.

Draining the whole microtask queue in one go means no task can slip between the links of a .then chain — no timer, no event, no render. It is not fully atomic, though: other microtasks can interleave. Two chains started side by side alternate link by link (a1, b1, a2, b2, …).

Promise.resolve()
  .then(() => console.log('a'))
  .then(() => console.log('b'));

setTimeout(() => console.log('timer'));

// a, b, timer

Each .then schedules the next microtask only when the previous one finishes, and the loop keeps draining until the queue is genuinely empty — including microtasks added while draining.

The starvation trap

Because the queue is drained completely, a microtask that schedules another microtask forever will freeze the page. Timers never get a turn, and neither does rendering.

function spin() {
  Promise.resolve().then(spin); // ❌ page is now frozen
}
spin();

The same loop with setTimeout is harmless — each iteration is a separate task, so the browser gets a chance to render and handle input in between.

function spin() {
  setTimeout(spin, 0); // ✅ slow, but the page stays responsive
}
spin();

This is the practical reason to know the difference. Anything recursive that runs on promises needs a task boundary somewhere.

Where rendering fits

In a browser, painting happens between tasks, never in the middle of one, and never during a microtask drain.

┌─ task ─┐ ┌ microtasks ┐ ┌─ render ─┐ ┌─ task ─┐ ┌ microtasks ┐ ...

Two consequences worth remembering:

• A long synchronous loop blocks paint. The spinner you set just before it will never appear.
• Splitting heavy work across setTimeout calls lets frames render in between. requestAnimationFrame is the precise tool when the work is visual, since it runs immediately before the next paint.

async/await is the same machinery

await is promise callbacks with different syntax. Everything after an await is effectively the body of a .then, so it runs as a microtask.

async function run() {
  console.log('A');
  await null; // yields here
  console.log('B'); // microtask
}

run();
console.log('C');

// A, C, B

The function runs synchronously until the first await, then returns control. "C" runs, the stack empties, and only then does "B" resume. This is also why await inside a loop serializes the work — each iteration waits for its awaited value to settle before the next one begins. It does not give the browser a chance to render, though: resuming after an await is a microtask, so no task runs between iterations unless the awaited promise itself waits on one (such as a setTimeout).

Side-by-side

The rule of thumb

If ordering surprises you, ask two questions in order: has the call stack emptied yet, and is this a microtask or a task? Synchronous code finishes first, microtasks drain completely, then one task runs. In the browser that sequence is fixed, which is exactly why it works as a diagnostic — almost every "why did this log out of order" bug resolves against those three steps. (Node adds its own process.nextTick queue on top; see the notes below.)

Version and environment notes

• Promises are ES2015; async/await is ES2017.

• queueMicrotask() shipped in Node.js 11+ (October 2018). Browsers followed between late 2018 (Chrome 71) and early 2020 (Edge 79) — safe to assume in any current environment.

• Node.js splits tasks into phases (timers, pending callbacks, poll, check, close callbacks) and adds two queues that don't exist in the browser model:

  	Runs when
  process.nextTick	after the current operation; in CommonJS, before promise callbacks
  promise callbacks	right after the nextTick queue drains, before the next phase
  setImmediate	in the check phase, right after poll (I/O)

  The nextTick-first order holds in CommonJS only. An ES module's top-level code already runs as part of the microtask queue, so there promise callbacks run before nextTick ones. Node now marks process.nextTick as legacy and recommends queueMicrotask() instead.

  For interview purposes, the browser model above is almost always what's being asked about. Bring up Node's phases only if the question goes there specifically.

• To verify behavior for a given runtime, log the order directly — this article's opening snippet is a fast way to check any environment.

Check yourself

1. What does this print?

console.log('start');

setTimeout(() => console.log('timeout'), 0);

Promise.resolve()
  .then(() => console.log('promise 1'))
  .then(() => console.log('promise 2'));

console.log('end');

2. What does this print?

async function log() {
  console.log('A');
  await Promise.resolve();
  console.log('B');
}

console.log('1');
log();
console.log('2');

Sources

• MDN Web Docs — The event loop
• MDN Web Docs — In depth: Microtasks and the JavaScript runtime environment
• MDN Web Docs — await
• MDN Web Docs — async function
• MDN Web Docs — Window: requestAnimationFrame() method
• MDN Web Docs — Window: requestIdleCallback() method
• Node.js Docs — The Node.js Event Loop, Timers, and process.nextTick()
• Node.js Docs — process: process.nextTick() and queueMicrotask()