JavaScript runs on one thread. One. That is the whole reason async exists. If a single click handler blocked the thread for 200ms, the page would freeze.

The event loop is the traffic cop that lets a single-threaded language feel non-blocking. Master it and you will never again be surprised by output order. This is the single most-asked question in senior JS interviews.

The pieces on the table

• Call stack. Where synchronous code runs. One frame at a time.
• Web APIs (or Node APIs). The browser or Node itself owns these. setTimeout, fetch, DOM events. They run off-thread.
• Macrotask queue (a.k.a. task queue). Holds setTimeout, setInterval, I/O callbacks, UI events.
• Microtask queue. Holds Promise.then, queueMicrotask, MutationObserver callbacks.
• Event loop. A simple loop: if the stack is empty, drain the microtask queue completely, then take one macrotask, then repeat.

The key word in that diagram is all. Microtasks drain completely. If a microtask queues another microtask, that one runs in the same drain cycle before any macrotask gets a turn.

The famous output trap

Every interviewer asks some version of this. Predict the output.

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");

Step-by-step.

1. Step 1. console.log("A") runs synchronously. Prints A.
2. Step 2. setTimeout hands the callback to the Web API. After 0ms it goes into the macrotask queue.
3. Step 3. Promise.resolve().then(...) queues its callback into the microtask queue.
4. Step 4. console.log("D") runs synchronously. Prints D. Call stack is now empty.
5. Step 5. Event loop checks microtasks first. Drains. Prints C.
6. Step 6. Event loop takes one macrotask. Prints B.

Output: A D C B. Not A D B C. The Promise wins because microtasks always drain before the next macrotask.

Interview trap: setTimeout(fn, 0) is not zero. The 0 is a minimum delay before the task is eligible to run. Browsers also clamp nested timeouts to 4ms after several layers of nesting.

A realistic Swiggy example

console.log("Order placed");
 
setTimeout(() => console.log("SMS sent"), 0);
 
fetch("/charge").then(() => {
  console.log("UPI charged");
  Promise.resolve().then(() => console.log("Receipt logged"));
});
 
console.log("Showing loader");

Assuming fetch resolves quickly, the order is roughly.

1. Order placed (sync).
2. Showing loader (sync).
3. Microtasks drain. UPI charged, then the queued Receipt logged in the same drain.
4. Macrotask runs. SMS sent.

Notice that the SMS line, scheduled with setTimeout(fn, 0), runs AFTER both Promise callbacks. Even though it had a "0" delay. This is the single most common production bug, scheduling work with setTimeout and expecting it to beat a Promise.

Microtasks can starve macrotasks

Because microtasks drain completely, a runaway Promise chain can block the macrotask queue forever.

function spin() {
  Promise.resolve().then(spin);
}
spin(); // browser freezes, setTimeout callbacks never fire

Each then queues another microtask. The loop never gets to take a macrotask. The page becomes unresponsive. Useful trap to know exists, never useful to write.

If you genuinely need to yield to rendering, use setTimeout(fn, 0) or requestAnimationFrame. Both go through the macrotask path and give the browser a chance to paint.

Render step, between macrotasks

In browsers, the render step (style, layout, paint) happens between macrotasks, after microtasks have drained. Mutating the DOM inside a tight Promise chain delays the paint. That is why long synchronous loops feel laggy and async chunks feel smooth.

// Bad: blocks paint
for (let i = 0; i < 1_000_000; i++) updateCell(i);
 
// Better: yields between chunks
async function paintChunks() {
  for (let i = 0; i < 1_000_000; i++) {
    updateCell(i);
    if (i % 1000 === 0) await new Promise(r => setTimeout(r, 0));
  }
}

The await setTimeout yields a macrotask, lets the browser paint, then resumes.

Predict the output, harder version

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

Step by step.

1. Step 1. Sync prints 1.
2. Step 2. setTimeout queues macrotask 2.
3. Step 3. First .then queues microtask 3. The second .then is NOT queued yet, it only queues once the first resolves.
4. Step 4. Sync prints 5. Stack empty.
5. Step 5. Drain microtasks. 3 runs, which causes the next .then to queue. Still in the same drain cycle. 4 runs.
6. Step 6. Take one macrotask. 2 runs.

Output: 1 5 3 4 2.

Senior rule: microtasks drain completely before the next macrotask runs. If you can recite that one line and walk through a five-step trace on a whiteboard, you have passed the async section of every senior JS interview I have seen.