JavaScript Event Loop: Microtasks vs Macrotasks

The event loop is the mental model behind every async bug you've ever debugged. Once it clicks, "why did this log in that order?" stops being a mystery — and predicting output order is a staple frontend interview question. Here's the model, then the rule that answers most questions.

The pieces

• Call stack — where synchronous code runs, one frame at a time. JavaScript is single-threaded: only one thing executes at once.
• Web APIs / host — timers, network, DOM events. These run outside the engine and hand callbacks back when ready.
• Macrotask queue — callbacks from setTimeout, setInterval, I/O, UI events.
• Microtask queue — callbacks from resolved promises (.then/await) and queueMicrotask.
• The event loop — the coordinator that decides what runs next.

The one rule that answers most questions

After the call stack empties, the event loop drains the entire microtask queue before taking the next macrotask (and before the browser repaints). Microtasks can schedule more microtasks, which also run before the next macrotask.

That single rule explains the classic puzzle:

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

1 and 4 are synchronous. When the stack empties, the microtask (3) runs before the macrotask (2) — even though the timer is 0 — because microtasks always drain first.

Why this matters beyond puzzles

• Ordering bugs: state updates or logs appearing "out of order" almost always come from mixing micro/macro tasks.
• UI jank: long synchronous work blocks the stack, so nothing else — including rendering — can happen. Break it up or offload to a Web Worker.
• await surprises: await yields to the event loop; code after an await runs as a microtask continuation, not synchronously.

await in the model

async function run() {
  console.log('a');
  await null;          // yields here
  console.log('b');    // runs as a microtask continuation
}
run();
console.log('c');
// → a, c, b

Everything before the first await runs synchronously; everything after resumes as a microtask.

Common mistakes

• Assuming setTimeout(fn, 0) runs "immediately" — it waits for the next macrotask, after all microtasks.
• Blocking the main thread with heavy loops and wondering why the UI froze.
• Thinking await pauses the whole program — it only pauses that async function; other code keeps running.
• Creating microtask loops that starve rendering.

Where it shows up in interviews

"Explain the event loop" and "predict this output" are widely reported frontend staples, and the model underpins debounce, throttle, promises and Core Web Vitals answers — INP is, at its core, a question about how long you keep the call stack busy between interactions. Practise reasoning about snippets and implementing async utilities against real tests in Frontend Interview Prep.

Frequently asked questions

What's the difference between a microtask and a macrotask?

Microtasks come from resolved promises and queueMicrotask; macrotasks come from setTimeout, setInterval, I/O and UI events. After the stack empties, the loop drains all microtasks before the next macrotask — so a Promise.then runs before a setTimeout(0).

Why does Promise.then run before setTimeout?

Because promise callbacks are microtasks and setTimeout callbacks are macrotasks, and the event loop empties the entire microtask queue before taking the next macrotask.

Is the event loop a common interview question?

Yes — explaining it and predicting async output order are commonly-discussed frontend interview topics. See the related JavaScript interview questions, debounce vs throttle and React Hooks interview questions (useEffect timing is an event-loop question in disguise), and practise in Frontend Interview Prep.