Async JS and the Event Loop

Concept

JavaScript is single-threaded — one call stack (Lesson 2), one thing running at any given instant. On its own, that should mean a slow operation like a network request freezes everything else. It doesn't, because the JS Runtime Environment (Lesson 13) hands slow work off to the browser, and the event loop is the mechanism that decides when the results of that work are allowed back onto the call stack.

Key Words In Plain English

• Thread is one path of execution. Single-threaded means JavaScript runs your code on one thread, so it does one thing at a time.
• Synchronous code runs line by line, and each line finishes before the next one starts. Asynchronous work is started now, and its result is handled later, while other code keeps running.
• Call stack is the list of function calls running right now. The engine always runs the call on top.
• Web API is a feature that the browser (not the JavaScript engine) provides, such as setTimeout, fetch and DOM events. It does its work outside the call stack.
• Callback is a function that you give to other code so that it can call it later.
• Task (macrotask) queue — this lesson also calls it the callback queue — is a waiting line for finished work such as timer callbacks and click handlers. The event loop takes one item per turn.
• Microtask queue is a second, higher-priority waiting line for promise callbacks and queueMicrotask callbacks. It is emptied completely before the next task runs.
• Event loop is the runtime's loop that checks whether the call stack is empty and, if it is, moves the next waiting callback onto it.
• Promise is an object that stands for a result that is not ready yet. It is pending first, then fulfilled (success) or rejected (failure). .then() registers a function to run when it is fulfilled.
• async/await is a way to write promise code that reads like normal code. An async function always returns a promise. await pauses that function until a promise settles.
• Starvation is when something never gets its turn because other work keeps going first.
• Rendering (painting) is the browser drawing the page on the screen. requestAnimationFrame is a browser function that runs your function just before the next paint.
• libuv is the C library that gives Node.js its event loop and its asynchronous file and network work.

Why This Matters

• It's the single most commonly misunderstood part of JavaScript, and one of the most asked interview topics of all.
• It explains real bugs: why a setTimeout(fn, 0) never runs “immediately,” and why a chain of promises can starve a UI from updating.
• It's the final piece connecting every earlier lesson — the call stack, closures, and now the queues — into one complete mental model of what actually happens when a JS file runs.

The Front Desk — An Analogy

The Four Players

The event loop itself isn't a queue — it's the clerk: a continuous loop that checks “is the call stack empty?” and, the instant it is, decides what gets pulled onto it next, following the golden rule below.

The Golden Rule: Microtasks Drain First

Tracing The Classic Example

console.log("1: sync start");

setTimeout(() => {
  console.log("2: setTimeout callback");
}, 0);

Promise.resolve().then(() => {
  console.log("3: promise callback");
});

console.log("4: sync end");

// Output:
// 1: sync start
// 4: sync end
// 3: promise callback
// 2: setTimeout callback

1. The synchronous code runs first, fully

   "1: sync start" logs immediately. setTimeout hands its callback to the Web API and returns instantly — it does not wait, even with a delay of 0. Promise.resolve().then(...) registers its callback into the microtask queue. "4: sync end" logs.

2. The call stack is now empty — golden rule kicks in

   Before touching the callback queue at all, the event loop drains the microtask queue completely. There's exactly one microtask waiting: the promise callback.

3. "3: promise callback" runs

   The microtask queue is now empty.

4. Only now does the callback queue get its turn

   "2: setTimeout callback" finally runs — last, even though it was scheduled before the promise.

1console.log("1: sync start");
2 
3setTimeout(() => {
4  console.log("2: setTimeout callback");
5}, 0);
6 
7Promise.resolve().then(() => {
8  console.log("3: promise callback");
9});
10 
11console.log("4: sync end");

async/await — Microtasks In Disguise

async/await doesn't add a new queue or a new kind of scheduling — it is written on top of promises, so it follows exactly the same rules. Two facts explain every async puzzle:

• An async function runs synchronously, on the current call stack, right up to its first await. Calling it is not deferred.
• await pauses the function and schedules the rest of it as a microtask. The function returns a pending promise straight away, and the caller keeps running.

async function checkIn() {
  console.log("2: checkIn starts");
  await null;
  console.log("4: after await");
}

console.log("1: script start");
setTimeout(() => console.log("6: timeout"), 0);
checkIn();
Promise.resolve().then(() => console.log("5: then"));
console.log("3: script end");

// 1: script start
// 2: checkIn starts
// 3: script end
// 4: after await
// 5: then
// 6: timeout

1async function checkIn() {
2  console.log("2: checkIn starts");
3  await null;
4  console.log("4: after await");
5}
6 
7console.log("1: script start");
8setTimeout(() => console.log("6: timeout"), 0);
9checkIn();
10Promise.resolve().then(() => console.log("5: then"));
11console.log("3: script end");

Where Rendering Fits In The Loop

The browser paints the screen from the same thread that runs your JavaScript, so painting has to take a turn in the loop too. One full turn looks like this:

1. Run one task from the callback queue

   A timer callback, a click handler, the initial script — exactly one.

2. Drain the entire microtask queue

   Every promise callback and await continuation, including new ones added along the way.

3. Maybe render

   If it's time for a new frame (about every 16 ms on a 60 Hz screen; the browser may skip a frame when nothing changed), run requestAnimationFrame callbacks, recalculate styles and layout, and paint.

4. Repeat

   Pick the next task, and go round again.

Two practical rules fall straight out of that order. Any single task or microtask chain that runs for 300 ms delays the next paint by 300 ms — the page looks frozen, and clicks feel ignored. And visual updates belong in requestAnimationFrame, which runs right before the paint, rather than in a setTimeout that may fire between frames.

// Blocks rendering: the browser can't paint until this task ends
button.addEventListener("click", () => {
  box.style.transform = "translateX(0)";
  heavyWork(); // 300 ms of synchronous work — the page freezes
  box.style.transform = "translateX(200px)";
});

// Runs just before the next paint — the right place for visual updates
let x = 0;
function animate() {
  box.style.transform = `translateX(${x++}px)`;
  if (x < 200) requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

Starvation — When Microtasks Never Stop

function scheduleMicrotaskForever() {
  Promise.resolve().then(() => {
    console.log("microtask running...");
    scheduleMicrotaskForever(); // queues another one before this one even finishes
  });
}

scheduleMicrotaskForever();

setTimeout(() => {
  console.log("this setTimeout may never run");
}, 0);

1function loop() {
2  Promise.resolve().then(() => {
3    console.log("microtask");
4    loop(); // queues another before this one ends
5  });
6}
7 
8setTimeout(() => console.log("timeout"), 0);
9loop();

A Quick Note On Node.js

See It Live — DevTools

1. Paste the classic example into the console

   Confirm the output order matches the trace above.

2. Open the Performance tab and record

   Re-run the snippet with recording on — you'll see the synchronous block, then a microtasks marker, then the timer firing as a separate task.

3. Try nesting more .then() calls

   Chain three or four .then()s after the first — notice they all still run before the single setTimeout, because each one re-queues into the still-draining microtask queue.

4. Swap the delay to 1000

   The relative order doesn't change — the promise callback still always wins, regardless of the timer's delay, because the golden rule isn't about speed, it's about queue priority.

Common Misconceptions

Interview Questions

Tying All 14 Lessons Together