🔄 JavaScript Event Loop Explained

The Runtime at a Glance

In the previous lesson you saw that async callbacks run "later." The event loop is how "later" is decided. To understand it, picture the four parts of the JavaScript runtime working together.

🍳 A kitchen analogy. One chef (the call stack) can only cook one dish at a time. Assistants and appliances (the Web APIs) handle slow tasks — a timer, an oven — in the background. Finished tickets pile up on a rail (the queues). A manager (the event loop) hands the chef the next ticket, but only when the chef's hands are empty.

• Call stack — where your code actually runs, one frame at a time.
• Web APIs — browser features (timers, network, DOM events) that do slow work off the stack.
• Task queue (macrotasks) — finished callbacks from timers, events, etc., waiting their turn.
• Microtask queue — higher-priority callbacks, mainly from Promises.
• Event loop — the loop that feeds queued callbacks onto the stack when it's empty.

The Call Stack

The call stack tracks where you are in the program. When a function is called it's pushed onto the stack; when it returns it's popped off. Because JavaScript is single-threaded, there is exactly one call stack, and only the frame on top is running.

Watching the stack grow and shrink

function multiplyByTwo(num) {
  return num * 2;
}

function calculate(num) {
  return multiplyByTwo(num) + 10;
}

function printResult(num) {
  const result = calculate(num);
  console.log(result);
}

printResult(5); // logs 20

This is Last In, First Out (LIFO): the most recently pushed function is the first to finish. It's also why error messages show a "stack trace" — it's literally a snapshot of the stack when things went wrong.

function crash(n) {
  return crash(n + 1); // never returns — no base case
}
crash(1); // RangeError: Maximum call stack size exceeded

Web APIs: The Background Helpers

Plain JavaScript has no ability to "wait two seconds" or "make a network request." Those powers come from the host environment — the browser (or Node.js) — through Web APIs. When you call one, the work leaves the call stack and runs in the background.

Common Web APIs

• Timers: setTimeout, setInterval
• Networking: fetch, XMLHttpRequest
• DOM events: click, scroll, keydown
• Others: Geolocation, WebSockets, and many more

What happens when you call one

1. You hand the Web API a callback (e.g. setTimeout(cb, 2000)).
2. The call stack keeps running the rest of your code — it does not wait.
3. The Web API does its slow work in the background (counts down the timer).
4. When done, it places your callback into the appropriate queue — not directly onto the stack.

console.log('Start');

setTimeout(function timeoutCallback() {
  console.log('Runs later (after ~2s)');
}, 2000);

console.log('End');

// Output:
// Start
// End
// Runs later (after ~2s)

Task Queue vs Microtask Queue

Finished callbacks don't run immediately — they line up in a queue and are processed First In, First Out (FIFO). Crucially, there are two queues with different priorities.

Priority in action

console.log('Start');

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

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

console.log('End');

// Output:
// Start
// End
// Promise (microtask)
// Timeout (macrotask)

Even though both are "immediate," the Promise's microtask runs before the setTimeout macrotask. That's because after the synchronous code finishes, the event loop drains all microtasks before it will pick up even a single macrotask.

The Event Loop Algorithm

The event loop is astonishingly simple for how much it enables. It runs forever, following this cycle:

1. Run synchronous code until the call stack is empty.
2. Drain the microtask queue completely — run every microtask, including any new microtasks they schedule.
3. Take one task from the task queue and push it onto the stack; run it to completion.
4. (The browser may render here.)
5. Go back to step 2 and repeat.

Tracing a Full Example

Let's apply the algorithm to a program that mixes all the pieces. Read it, predict the output, then check yourself.

console.log('1: script start');

setTimeout(function timeout1() {
  console.log('5: setTimeout 1');
  Promise.resolve().then(() => console.log('6: promise inside timeout'));
}, 10);

setTimeout(function timeout2() {
  console.log('7: setTimeout 2');
}, 0);

Promise.resolve().then(function promise1() {
  console.log('3: promise 1');
  Promise.resolve().then(() => console.log('4: promise 2 (nested)'));
});

console.log('2: script end');

1: script start
2: script end
3: promise 1
4: promise 2 (nested)
7: setTimeout 2
5: setTimeout 1
6: promise inside timeout

Why that order

• 1, 2 — synchronous code runs first, top to bottom.
• 3, 4 — the stack is empty, so microtasks drain: promise 1 runs and schedules a nested microtask, which also runs before we touch any timer.
• 7 — now one macrotask: setTimeout 2 (0 ms) fires before setTimeout 1 (10 ms).
• 5, 6 — the next macrotask, setTimeout 1, logs and schedules a microtask; that microtask drains immediately after this task, before any further macrotask.

Trace it with the one-sentence rule and it's mechanical, not mysterious.

Keeping the Thread Free

Because everything shares one stack, a long synchronous task starves the queues — no clicks, no rendering, no timers fire. Here's how to stay responsive.

Chunk heavy work

Split a big loop into slices and yield to the event loop between them so the browser can paint and handle input:

function processInChunks(items, work, chunkSize = 100, start = 0) {
  const end = Math.min(start + chunkSize, items.length);
  for (let i = start; i < end; i++) {
    work(items[i]);
  }
  if (end < items.length) {
    // Yield to the event loop, then continue the next chunk
    setTimeout(() => processInChunks(items, work, chunkSize, end), 0);
  }
}

Offload truly heavy computation to a Web Worker

For CPU-bound work, a Web Worker runs on a genuinely separate thread and communicates by messages, so the main thread stays free:

// main.js
const worker = new Worker('worker.js');
worker.addEventListener('message', (e) => {
  console.log('Worker result:', e.data);
});
worker.postMessage(bigDataset);

// worker.js
self.addEventListener('message', (e) => {
  const result = doHeavyComputation(e.data);
  self.postMessage(result);
});

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• MDN — The event loop
• Jake Archibald — Tasks, microtasks, queues and schedules
• Node.js — The event loop, timers, and process.nextTick

🚀 What's Next?

Now that you know when callbacks run, we'll look at the oldest way to schedule them: callback functions — their patterns, their pitfalls (hello, callback hell), and why Promises came along.