Event Loop

How JavaScript handles asynchronous code — the call stack, heap, task queue, microtask queue, and why JavaScript is single-threaded but non-blocking.

What it is, in plain English: The event loop is the mechanism that allows JavaScript to be non-blocking despite running on a single thread. It continuously checks the call stack — if it's empty, it picks the next task from the queues and runs it. There are two queues: the microtask queue (Promises, queueMicrotask) which drains completely before each macrotask, and the macrotask queue (setTimeout, setInterval, I/O) which runs one task at a time. Understanding this explains every async timing puzzle.

Where this bites you

The delay you give setTimeout is a minimum, not an appointment. When the time is up, the callback joins the queue, but it can only run once the call stack is empty. If your code is busy with a long synchronous job, every timer, click handler and network callback waits for it. A 100 ms timer firing after a full second is the result, and in a browser the page stays frozen for that whole second.

const start = Date.now();
setTimeout(() => {
  console.log(`timer fired after ${Date.now() - start} ms (asked for 100)`);
}, 100);

// one second of synchronous work, e.g. processing a big array
while (Date.now() - start < 1000) {}
console.log("work done");
// work done
// timer fired after 1009 ms (asked for 100)   // timer fired after 1009 ms (asked for 100)lt;- exact ms vary run to run

Why JavaScript can do many things without threads

JavaScript runs on a single thread — it can only do one thing at a time. Yet it handles network requests, timers, user clicks, and file reads without freezing. How? The event loop.

The three pieces

Call Stack — where your code runs, one function at a time.
Web APIs / Node APIs — where async work actually happens (browser timer, network, file system) — outside the JS thread.
Queue — completed async work waits here to run on the stack.

// This is what happens step by step:
console.log("A");                    // 1. push to stack → run → pop

setTimeout(() => {
  console.log("C");                  // 4. much later: moved to queue → stack → run
}, 1000);                            // 2. handed to browser timer API (not JS)

console.log("B");                    // 3. push to stack → run → pop

// Output: A  B  (1 second pause)  C
// The stack never "waited" — it moved on to B while the timer ran elsewhere

The event loop in plain English

// Pseudocode of what the event loop does forever:
while (true) {
  // 1. Run ALL synchronous code until the call stack is empty
  // 2. Drain the ENTIRE microtask queue (Promises)
  // 3. Run ONE macrotask (setTimeout callback, I/O callback, etc.)
  // 4. Drain microtasks again
  // 5. Maybe repaint the screen (browser only)
  // 6. Repeat
}

Two types of async tasks

// MICROTASKS — run BEFORE the next macrotask
// Sources: Promise .then/.catch, queueMicrotask(), async/await resumes
Promise.resolve().then(() => console.log("microtask"));

// MACROTASKS — run one at a time, after all microtasks drain
// Sources: setTimeout, setInterval, setImmediate (Node), I/O callbacks
setTimeout(() => console.log("macrotask"), 0);

console.log("sync");

// Output:
// sync          ← call stack runs first
// microtask     ← microtask queue drains before macrotask
// macrotask     ← macrotask runs after

The classic ordering quiz

console.log("1");

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

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

console.log("5");

// Can you predict the order?
// Answer: 1 → 5 → 3 → 4 → 2
//
// Why: 1 and 5 run synchronously.
// Promise microtasks (3, 4) run before setTimeout macrotask (2).
// And .then() chains: 3 runs first, which queues 4, then 4 runs — all before 2.

Try It Yourself

// The execution order proof — run this and predict the output
console.log("1 — synchronous (call stack)");

setTimeout(() => console.log("5 — macrotask (setTimeout 0ms)"), 0);

Promise.resolve()
  .then(() => console.log("3 — microtask 1"))
  .then(() => console.log("4 — microtask 2"));

queueMicrotask(() => console.log("3b — microtask (queueMicrotask)"));

console.log("2 — synchronous (call stack)");

// Output order: 1 → 2 → 3 → 3b → 4 → 5
// Rule: sync → all microtasks → one macrotask → all microtasks → one macrotask...

// Starving the event loop — DON'T do this:
// while (true) {}  // blocks forever, nothing else runs

// Yielding to let the event loop breathe:
async function processLargeArray(items) {
  const CHUNK = 1000;
  const results = [];
  for (let i = 0; i < items.length; i += CHUNK) {
    const chunk = items.slice(i, i + CHUNK);
    results.push(...chunk.map(x => x * 2));
    // Yield after each chunk — lets other tasks run:
    await new Promise(resolve => setTimeout(resolve, 0));
  }
  return results;
}

// Demonstrate microtask queue draining before macrotask:
let microtaskCount = 0;
function addMicrotasks(n) {
  if (n === 0) { console.log(`All ${microtaskCount} microtasks ran before setTimeout`); return; }
  microtaskCount++;
  Promise.resolve().then(() => addMicrotasks(n - 1));
}
addMicrotasks(3);
setTimeout(() => console.log("setTimeout fires AFTER all microtasks"), 0);

Microtask starvation, rendering, and Node.js differences

Microtask queue can starve macrotasks

// If you keep adding microtasks, macrotasks (and rendering) never run:
function addMicrotasks() {
  Promise.resolve().then(() => addMicrotasks());  // infinite microtask loop!
}
// addMicrotasks();  // This freezes the page — setTimeout never fires

// The fix: use setTimeout to yield:
function yieldToEventLoop() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processWithYield(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i]);
    if (i % 100 === 0) await yieldToEventLoop();  // let other tasks run
  }
}

The fix is the same idea as yieldToEventLoop() above: split the long job into chunks and hand control back to the event loop between them. Each chunk is scheduled with setTimeout(..., 0), so callbacks that are already waiting get to run in between. The total work takes the same time, but nothing waits behind all of it. (For work that is heavy all the way through, move it to a Web Worker or a worker thread instead.)

const start = Date.now();
setTimeout(() => {
  console.log(`timer fired after ${Date.now() - start} ms (asked for 100)`);
}, 100);

// the same second of work, in ten 100 ms chunks
function work(chunk) {
  const t = Date.now();
  while (Date.now() - t < 100) {}
  if (chunk < 9) setTimeout(() => work(chunk + 1), 0);   // let waiting callbacks run
  else console.log("work done");
}
work(0);
// timer fired after 100 ms (asked for 100)    // timer fired after 100 ms (asked for 100)lt;- exact ms vary run to run
// work done

Browser rendering sits between macrotasks

// The browser render step happens between macrotasks (roughly every 16ms at 60fps)
// It does NOT happen between microtasks.

// requestAnimationFrame fires just before each render:
function animate() {
  // update position
  requestAnimationFrame(animate);  // schedule next frame
}
requestAnimationFrame(animate);

// Heavy computation blocks rendering — use setTimeout chunking or Web Workers:
// setTimeout(() => processChunk(), 0) between chunks lets the browser repaint

Node.js event loop phases (libuv)

// Node.js has more phases than the browser:
// 1. timers       — setTimeout, setInterval callbacks
// 2. pending      — I/O callbacks from previous cycle
// 3. idle/prepare — internal Node use
// 4. poll         — wait for new I/O events
// 5. check        — setImmediate callbacks
// 6. close        — close event callbacks

// setImmediate runs AFTER I/O in the current cycle (before next timers):
setImmediate(() => console.log("setImmediate"));
setTimeout(()   => console.log("setTimeout"), 0);
// In Node.js, order between these two is not guaranteed outside I/O context

// process.nextTick — runs before any I/O, even before Promise microtasks:
process.nextTick(() => console.log("nextTick — before Promise!"));
Promise.resolve().then(() => console.log("Promise.then"));
// Output in a CommonJS file: nextTick → Promise.then
// In an ES module (.mjs, or "type": "module") the order is reversed: Promise.then → nextTick

async/await and the event loop

// Each 'await' suspends the function and creates a microtask:
async function example() {
  console.log("A");           // sync
  await Promise.resolve();    // suspends here, schedules resume as microtask
  console.log("C");           // runs as microtask after B
}

example();
console.log("B");  // runs sync before C

// Output: A → B → C

Spec details — jobs, agents, and the HTML event loop

ECMAScript jobs vs HTML event loop

ECMAScript (§9.4) defines Jobs — abstract units of work scheduled via the EnqueueJob abstract operation. Microtasks correspond to the PromiseJobs job queue in the spec. The spec does not define macrotasks, timers, or I/O — those come from the host environment.

The HTML spec (whatwg.org/html) defines the actual event loop algorithm with steps: (1) select the oldest task from a task queue, (2) run it, (3) perform a microtask checkpoint (drain all microtasks), (4) optionally render, (5) repeat.

Microtask checkpoint

The perform a microtask checkpoint operation runs after every task and after script evaluation. It loops until the microtask queue is empty — which is why queuing a microtask inside a microtask callback still runs before the next macrotask. The queue can grow during draining; draining doesn't stop until it's truly empty.

Agents and the concurrency model

// Each JavaScript realm runs in an "Agent" — a single thread with its own event loop.
// Agents communicate only via:
// 1. SharedArrayBuffer + Atomics (shared memory, requires COOP+COEP headers)
// 2. postMessage (message passing, the data is copied via structured clone)

// Web Workers are separate agents:
const worker = new Worker("worker.js");
worker.postMessage({ data: [1,2,3] });         // structured clone
worker.onmessage = (e) => console.log(e.data); // result comes back as macrotask

Official Sources

The Codex links only to official documentation and the ECMAScript specification. No third-party tutorials.