The Event Loop

▶ Watch this first

The JavaScript Event Loop — Lydia Hallie

Best visual explainer of the call stack and the task/microtask queues. Watch it once before reading — then the §3 ordering example below will click instantly. Open on YouTube ↗

▶ click to play

1The frame — one thread, run-to-completion

JavaScript runs on one thread with one call stack. The cardinal rule is run-to-completion: once a function starts, it runs to the end without interruption — no other JS (no event handler, no timer, no promise callback) can sneak in mid-function. The event loop is simply the mechanism that, whenever the stack is empty, decides what to run next. [MDN]

It chooses from two queues, and the distinction between them is the whole lesson:

2The one rule — the loop's order of operations

Memorize this cycle; almost every interview question is a corollary of it: [Jake Archibald]

1. Run one macrotask — e.g. the initial <script>, or one setTimeout callback. It runs to completion.
2. Drain the entire microtask queue — run microtasks until the queue is empty, including microtasks scheduled by other microtasks. This happens after every task.
3. Maybe render — if it's time for a frame (~every 16.7ms at 60fps, not every turn): run requestAnimationFrame callbacks, then style → layout → paint.
4. Back to step 1 — pick the next macrotask.

Two consequences carry most of the weight:

• Microtasks always beat macrotasks. A Promise.then queued after a setTimeout(…,0) still runs first — the whole microtask queue drains before the next task.
• Microtasks run before rendering. They're your chance to act on the just-finished work before the user sees a frame — but it also means a runaway microtask chain blocks paint entirely (§5).

3Walk the classic example

The question you'll get asked. Predict the output before reading on. (Watching the queues move helps it stick — Lydia Hallie's animated event-loop walk-through is the best visual for this.)

console.log('1 · script start');
setTimeout(() => console.log('2 · setTimeout'), 0);   // macrotask
Promise.resolve()
  .then(() => console.log('3 · promise A'))            // microtask
  .then(() => console.log('4 · promise B'));           // microtask (chained)
console.log('5 · script end');

Why, step by step:

• The whole script is one macrotask. Sync lines run top-to-bottom → 1, then 5. The setTimeout and .then only queue callbacks; they don't run yet.
• Script finishes → stack empty → drain microtasks: 3 runs, which resolves the next .then and queues 4; the loop keeps draining → 4 runs. Both microtasks clear before any task.
• Microtask queue empty → loop takes the next macrotask → 2.

4The scheduling toolbox — where to put work

A Lead doesn't just know the order — they know which queue to choose for a piece of work. The map: [MDN]

5Why a Lead cares — the loop is your perf model

This isn't trivia; it's the engine under every responsiveness problem you've studied:

• Long task = frozen page. Because of run-to-completion, one long synchronous function (or hydration, Lesson 10) monopolises the only thread — no task, microtask, render, or input handler can run until it finishes. That's a long task (>50ms) and it's the direct cause of poor INP (Lesson 07). Fix: break it up and yield (scheduler.yield/setTimeout) or move it to a Web Worker.
• Microtask starvation. A microtask that keeps queueing more microtasks never lets the loop reach render (step 3) — the page freezes harder than a setTimeout loop would, because tasks at least yield between turns. Don't recurse in microtasks; use a task to break the chain.
• Ordering bugs are race conditions. “It works locally but flickers in prod” is often two updates landing in the wrong order across micro/macrotask boundaries. Reasoning about the loop is how you debug them.

Deep dive — chunking a long task with scheduler.yield()

The headline INP fix, made concrete. You don't make the work smaller — you make it interruptible. Break the loop into chunks and, between them, hand the thread back so the browser can paint and dispatch pending input, then resume. [web.dev]

async function process(items) {
  let last = performance.now();
  for (const item of items) {
    doExpensiveWork(item);
    if (performance.now() - last > 50) {   // yield on a ~50ms budget, not per item
      await scheduler.yield();              // ← ends this task; resumes as a new, prioritised task
      last = performance.now();
    }
  }
}

What await scheduler.yield() does: it ends the current task right there. The rest of the loop becomes a new task; in the gap the loop is free to render and dispatch queued input, then your continuation runs. One 300ms task becomes six ~50ms tasks with usable gaps — a tap now waits ~50ms (one chunk), not 300ms.

Why scheduler.yield() specifically, and not the obvious alternatives:

The await Promise row is the trap from the quiz (Q10): a microtask doesn't yield to render/input. The setTimeout(0) row works but sends your continuation to the back of the task queue, so unrelated tasks delay it. scheduler.yield() is the one that yields and resumes with priority — yield to the browser without losing your place.

7Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.