The Event Loop: Complete Model

The Interview Question Everyone Gets Wrong

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

Most developers know the output is 1, 4, 3, 2. But ask why — why does the Promise callback run before setTimeout even though both are "asynchronous" and setTimeout has a delay of 0? — and you'll separate the engineers who memorized the answer from those who understand the machine.

The answer is the event loop. Not the simplified "there's a queue" version. The actual algorithm.

The Mental Model

The Algorithm

The HTML specification defines the event loop in Section 8.1.7. Here's what actually happens, stripped of spec jargon:

while (true) {
  // 1. Pick the oldest task from a task queue (if any)
  task = pickOldestTaskFromAnyQueue();

  if (task) {
    // 2. Execute it (this runs on the call stack)
    execute(task);
  }

  // 3. Microtask checkpoint — drain ALL microtasks
  while (microtaskQueue.length > 0) {
    execute(microtaskQueue.shift());
  }

  // 4. If it's time to render (~16.6ms for 60fps):
  if (shouldRender()) {
    // 4a. Run requestAnimationFrame callbacks
    runRAFCallbacks();

    // 4b. Style, Layout, Paint
    render();
  }

  // 5. If nothing to do, wait for a task to appear
}

That's it. That's the entire event loop. Every async behavior you've ever observed — setTimeout ordering, Promise resolution timing, animation frame scheduling — follows from this algorithm.

What Counts as a Task (Macrotask)?

A task is a discrete unit of work scheduled by the browser or by APIs:

• setTimeout / setInterval callbacks
• I/O completion callbacks
• UI events (click, keydown, scroll)
• MessageChannel / postMessage
• requestIdleCallback

Each task runs to completion. The engine cannot interrupt a task halfway through.

What Counts as a Microtask?

Microtasks are higher-priority work that must complete before the event loop moves on:

• Promise.then / catch / finally callbacks
• queueMicrotask() callbacks
• MutationObserver callbacks

The critical rule: all microtasks are drained after every task — including microtasks that are scheduled by other microtasks. This is the key to understanding Promise timing.

The Task Queue Is Not a Single Queue

The spec says the browser can have multiple task queues with different priorities. In practice, browsers have:

• An input event queue (clicks, keyboard) — highest priority
• A timer queue (setTimeout, setInterval)
• A networking queue (fetch completions)
• A rendering queue (internal)

The browser chooses which queue to pick from. This is why user input events feel responsive even when timers are backed up — the browser prioritizes the input queue.

Deep Explanation: Walking Through the Algorithm

Step through the code below to see exactly how the event loop processes each line, manages the call stack, and drains the queues:

The output is 1, 4, 3, 2. Not because of magic rules about "microtasks before macrotasks." Because of the algorithm: after each task, drain all microtasks, then pick the next task.

Production Scenario: The Long Task Problem

Here's where the event loop model saves you in production. Imagine a dashboard that processes 100,000 data points to render a chart:

// Bad: blocks for 200ms — no rendering, no user input
function processData(data) {
  const results = [];
  for (let i = 0; i < data.length; i++) {
    results.push(heavyComputation(data[i]));
  }
  renderChart(results);
}

During that 200ms, the event loop is stuck on a single task. The browser cannot:

• Respond to clicks or scrolling
• Run requestAnimationFrame callbacks
• Render any DOM changes
• Process any other timers

The fix is to break the work into multiple tasks, giving the event loop breathing room:

// Good: yields to the event loop after each chunk
function processDataChunked(data) {
  const results = [];
  let i = 0;
  const CHUNK_SIZE = 1000;

  function processChunk() {
    const end = Math.min(i + CHUNK_SIZE, data.length);
    while (i < end) {
      results.push(heavyComputation(data[i]));
      i++;
    }

    if (i < data.length) {
      // Schedule next chunk as a new task — lets rendering happen
      setTimeout(processChunk, 0);
    } else {
      renderChart(results);
    }
  }

  processChunk();
}

Each setTimeout call creates a new task. Between tasks, the event loop runs the microtask checkpoint and (potentially) renders. The page stays responsive.

The Render Step in Detail

The render step doesn't run on every event loop iteration. It runs approximately every 16.6ms (for a 60fps display), and only if:

1. There are visual changes to process
2. The document is visible (not in a background tab)
3. The browser determines it's time based on the display refresh rate

When it does run, the order is:

1. requestAnimationFrame callbacks — your chance to make DOM changes
2. Style recalculation — compute final CSS values
3. Layout — calculate geometry (widths, heights, positions)
4. Paint — create the visual representation
5. Composite — combine layers and send to the GPU

Common Mistakes

Challenge: Predict the Timing

Challenge: Event Loop Ordering

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

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

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

console.log('E');

Key Rules