Event Loop

1The Problem the Event Loop Solves

JavaScript has one call stack and runs on one thread. Yet it can handle timers, network responses, and user input without freezing. The event loop is the mechanism that makes this possible — it coordinates the call stack, a set of task queues, and the browser/Node APIs that handle async work outside of JavaScript itself.

2The Four Pieces

┌─────────────┐     ┌───────────────────────────┐
│  Call Stack   │     │  Web APIs / Node APIs       │
│  (runs code)  │     │  (setTimeout, fetch, fs...)  │
└──────┬───────┘     └──────────────┬───────────────┘
        │                              │ (when ready)
        │                              ▼
        │                    ┌───────────────────┐
        │                    │  Callback / Task    │
        │                    │  Queues (macro/micro)│
        │                    └─────────┬───────────┘
        ▲                              │
        └──────────── Event Loop ◄─────┘
        (moves queued callbacks onto the stack
          ONLY when the stack is completely empty)

1. Call Stack — where currently-executing synchronous code lives (see the Call Stack topic).
2. Web/Node APIs — the runtime environment (not JavaScript itself) that handles timers, I/O, and network requests in the background.
3. Task Queues — where completed async callbacks wait their turn (split into microtasks and macrotasks — full detail in the next topic).
4. The Event Loop — a continuously running process that checks: "is the call stack empty? If so, take the next callback from the queue and push it onto the stack."

3Walking Through an Example

console.log("1");

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

console.log("3");

Step by step:

1. console.log("1") runs synchronously on the call stack, prints 1.
2. setTimeout(...) is handed off to the Web/Node API layer, which starts a 0ms timer. The call stack is NOT blocked waiting for it.
3. console.log("3") runs synchronously, prints 3.
4. The synchronous script finishes; the call stack is now empty.
5. The timer (already expired) has placed its callback in the macrotask queue.
6. The event loop sees the empty stack, takes the callback from the queue, pushes it onto the stack.
7. It runs, prints 2.

Result: 1, 3, 2 — never 1, 2, 3, no matter how short the timeout delay is.

4The Golden Rule

The event loop never interrupts running synchronous code. It only ever moves a queued callback onto the stack when the stack is completely empty. This is why a long synchronous operation (see the Call Stack topic) blocks every pending timer and network response, no matter how "urgent" they are.

5Why setTimeout(fn, 0) Isn't Instant

Even with a 0ms delay, the callback still has to:

1. Wait for the timer to be registered by the Web/Node API layer.
2. Wait for the CURRENT synchronous code to finish completely.
3. Wait for the event loop to notice the stack is empty and pull it off the queue.

None of that is instantaneous, and step 2 alone can take arbitrarily long if the current script keeps running.

(Full depth on microtasks vs macrotasks is its own topic — this section focuses specifically on how the event loop sequences them.)

1Two Queues, Not One

The event loop actually checks two separate queues, with strict priority: the microtask queue (Promise callbacks, queueMicrotask) is always fully drained before the loop touches the macrotask queue (setTimeout, setInterval, I/O callbacks) again.

console.log("1: sync");

setTimeout(() => console.log("4: macrotask"), 0);

Promise.resolve().then(() => console.log("3: microtask"));

console.log("2: sync");

Output: 1, 2, 3, 4 — the microtask (Promise callback) always runs before the macrotask (setTimeout), even though the setTimeout line appeared first in the source.

2The Precise Loop Algorithm

loop forever:
  1. Run the call stack until empty (all currently synchronous code).
  2. Drain the ENTIRE microtask queue — run every microtask, even
     new ones added WHILE draining (they still get processed
     before moving on).
  3. Pick exactly ONE macrotask from the macrotask queue, run it
     (which itself may add more microtasks — go back to step 2
     immediately after).
  4. (In browsers) possibly re-render the page.
  5. Repeat from step 1.

The critical detail: microtasks are drained completely, including any new microtasks scheduled by earlier ones, before even a single macrotask is allowed to run.

3Microtasks Can Starve Macrotasks

function scheduleForever() {
  Promise.resolve().then(scheduleForever); // keeps adding a new microtask, forever
}
scheduleForever();
setTimeout(() => console.log("this may never run"), 0); // starved — the microtask queue never empties

Because the loop must fully drain the microtask queue before touching a macrotask, an infinitely self-scheduling microtask chain can starve all timers and I/O indefinitely — a real (if uncommon) production bug pattern.

4A Complete Worked Example

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve()
  .then(() => console.log("C"))
  .then(() => console.log("D"));

setTimeout(() => console.log("E"), 0);

Promise.resolve().then(() => console.log("F"));

console.log("G");

Trace:

1. Synchronous: A, G print immediately.
2. Stack empty → drain microtasks: C runs, schedules the next .then (D) as a NEW microtask; F runs (was already queued); then D runs (queued during step 2, but the queue isn't considered "empty" until it truly has nothing left).
3. Macrotask queue: B, then E (in the order their timers were registered).

Final order: A, G, C, F, D, B, E.

   ┌───────────────────────────┐
┌─▶│           timers            │  setTimeout / setInterval callbacks whose time has come
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │      pending callbacks      │  some system-level callbacks deferred from the previous cycle
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │       idle, prepare          │  internal use only
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │            poll              │  retrieve new I/O events; execute I/O-related callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │            check             │  setImmediate() callbacks specifically
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │        close callbacks        │  e.g. socket.on('close', ...)
│  └─────────────┬─────────────┘
└────────────────┘

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));

⚠️ Common Pitfalls

1. Assuming setTimeout(fn, 0) beats a Promise .then() — it never does; ALL pending microtasks run first, unconditionally.
2. Chained .then() calls "jumping the queue" unexpectedly — each .then() adds a NEW microtask when its predecessor resolves; a long .then() chain can interleave with other already-queued microtasks in ways that surprise people expecting strict FIFO across unrelated chains.
3. Not realizing rendering (in browsers) happens only between macrotasks, not between every microtask — a runaway microtask chain can also block visual updates, not just other timers.
4. Debugging "impossible" ordering without accounting for the fact that microtasks scheduled DURING microtask draining still get processed in the same pass.

📋 Quick Reference

sync code           → runs first, always, completely
microtasks           → ALL drained next, including newly-added ones, before any macrotask
one macrotask         → runs, may add more microtasks → drain those → repeat
Promise.then          → microtask
setTimeout/setInterval → macrotask

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

Source: js_event_loop_theory_1.md, js_event_loop_theory_2.md · generated by tools/build_lessons.py