The Event Loop, the Picture: One Thread, a Stack and Two Queues

Rafi builds a quiz app. When a student clicks "Submit", he wants a message to appear at once, then the grading to start. So he writes setTimeout(showMessage, 0), thinking zero means "now". Then the grading loop runs, and the message appears only after it. His zero-millisecond timer waited the whole time.

Rafi's timer did not break. It did exactly what JavaScript promises. A timer's callback never cuts into code that is already running. It waits until the stack is empty, and then the event loop hands it over. This module is about that loop. Once you can see it, the print order of any async program stops being a surprise.

One thread, one call stack

JavaScript runs your code on one thread. A thread is one line of work: it does one thing, then the next. There is no second worker in your program that could run a timer's callback while your loop is busy.

That one thread keeps a call stack. Module 5 showed it: each function call pushes a frame, and each return pops one. The main script itself is the bottom frame. While anything is on the stack, the thread is busy.

const start = Date.now();
setTimeout(() => {
  const waited = Date.now() - start;
  console.log("timer ran, waited 200 ms or more:", waited >= 200);
}, 0);
let spins = 0;
while (Date.now() - start < 200) spins++;
console.log("loop done");

loop done
timer ran, waited 200 ms or more: true

The timer asked for 0 ms. The loop kept the stack busy for 200 ms, so "loop done" prints first. Only then does the timer's callback run, and the second line confirms it waited the whole 200 ms.

The host does the waiting

If JavaScript has one thread, who counts the milliseconds? Not your code. The host does: the program that runs JavaScript. In a browser the host is the browser itself; on our Playground and on servers it is Node.js.

The host offers APIs that wait for things: timers, file reads, network replies, clicks. In a browser they are called the Web APIs. Node has its own set. When you call setTimeout(cb, 100), you hand cb to the host and get control back at once. setTimeout itself takes almost no time.

console.log("before");
const id = setTimeout(() => console.log("callback"), 100);
console.log("setTimeout returned, the timer id is an object:", typeof id === "object");
console.log("after");

before
setTimeout returned, the timer id is an object: true
after
callback

setTimeout returns at once with a timer id, and the script keeps going. In Node that id is an object; in a browser it is a number. Lesson 02 uses the id to cancel a timer.

The task queue

When the host's timer is done, the callback cannot run straight away, because the stack might be busy. So it joins a line: the task queue, also called the macrotask queue or callback queue. Timers, finished file reads and click events all wait there, first in, first out.

A task is one callback from that queue, run from start to finish. Nothing interrupts a task. That is the "run to completion" rule, and it is why Rafi's loop could not be cut into.

The microtask queue

There is a second, smaller line with a higher priority: the microtask queue. You can put a callback there with queueMicrotask(cb). A promise's .then(cb) also puts its callback there. Module 13 teaches promises properly; here a then is simply "a microtask".

Here is why it has priority. After each task, and after the main script, the loop runs every microtask before the next task. That includes microtasks that other microtasks queue while it works.

The loop: one rule, three steps

Now the whole picture fits in three steps, repeated forever:

1. Run the current task until the stack is empty. The first task is the main script.
2. Run every microtask, oldest first, until the microtask queue is empty.
3. Take the oldest task from the task queue, if there is one, and go back to step 1.

That is the event loop. When both queues are empty and no timer or read is pending, Node has nothing left to wait for, and the program ends.

Watch it on the classic puzzle. The widget runs the program with real timers and real microtasks, and records each moment. The program's own output appears at the bottom, line by line, in the order Node produced it.

Look at the moment the script ends. The timer is still with the host, and both microtasks are waiting. Step 2 of the loop runs them both. Only after that does the timer's callback reach the task queue and the stack. The last frame shows Node's real order: start, end, then, micro, timeout.

setTimeout(callback, ms);        // the host waits ms, then callback joins the TASK queue
queueMicrotask(callback);        // callback joins the MICROTASK queue
promise.then(callback);          // a microtask too (Module 13)

// the loop, forever:
// 1. run the current task until the stack is empty (first task: the main script)
// 2. run every microtask, new ones included
// 3. take the oldest task, go to 1

setTimeout(() => console.log("timer A"), 0);
console.log("sync 1");
queueMicrotask(() => console.log("micro A"));
setTimeout(() => console.log("timer B"), 0);
queueMicrotask(() => console.log("micro B"));
console.log("sync 2");

sync 1
sync 2
micro A
micro B
timer A
timer B

setTimeout(() => console.log("timer"), 0);
queueMicrotask(() => {
  console.log("micro 1");
  queueMicrotask(() => console.log("micro 2, queued by micro 1"));
});
console.log("script done");

script done
micro 1
micro 2, queued by micro 1
timer

let ready = false;
setTimeout(() => {
  ready = true;
}, 0);
console.log("ready:", ready);

ready: false

let done = false;
setTimeout(() => {
  done = true;
}, 10);
const start = Date.now();
while (!done && Date.now() - start < 300) {}
console.log("done after the loop:", done);

done after the loop: false

setTimeout(() => console.log("1"), 0);
queueMicrotask(() => console.log("2"));
setTimeout(() => console.log("3"), 0);
console.log("4");

6
timeout tea
log one
micro milk
log two
timeout cake
micro sugar

one
two
milk
sugar
tea
cake

const input = require("fs").readFileSync(0, "utf8");
const tokens = input.split(/\s+/).filter(Boolean);
let at = 0;
const next = () => tokens[at++];
const nextInt = () => Number(next());
const out = [];

// your code: read with next() and nextInt(), push every line of output to out

console.log(out.join("\n"));

4
100 30
0 0
20 500
5 5

const input = require("fs").readFileSync(0, "utf8");
const tokens = input.split(/\s+/).filter(Boolean);
let at = 0;
const next = () => tokens[at++];
const nextInt = () => Number(next());
const out = [];

// your code: read with next() and nextInt(), push every line of output to out

console.log(out.join("\n"));

100
1
500
5

4
timeout cat
log dog
micro owl
log ant
dog ant cat owl

const input = require("fs").readFileSync(0, "utf8");
const tokens = input.split(/\s+/).filter(Boolean);
let at = 0;
const next = () => tokens[at++];
const nextInt = () => Number(next());
const out = [];

// your code: read with next() and nextInt(), push every line of output to out

console.log(out.join("\n"));

wrong at 3

Next: every piece of the toolkit, one by one: setTimeout's real guarantee, setInterval, clearing, and the callback shapes.