JavaScript is single-threaded. One thread. One call stack. One thing at a time.
And yet — you've written code that fetches data from an API while animating a loading spinner while handling button clicks while running a countdown timer. How? How does one thread do all of that without freezing?
The answer is the event loop — arguably the most misunderstood piece of the JavaScript runtime. Most developers use it every day without ever truly seeing it. They write setTimeout, Promise.then(), async/await, and fetch() like they're magic spells, and they mostly work — until they don't.
Until you've hit a bug where a setTimeout(..., 0) fires after something it should have fired before. Until a Promise resolves in an order that makes no logical sense to you. Until your UI freezes solid because a loop ran too long. That's when you realize: you've been flying blind.
Understanding the event loop isn't just academic. It's the difference between writing JavaScript that works and writing JavaScript that you understand. It explains why async/await is not the same as threads, why microtasks beat macrotasks, and why your beautiful Promise chain sometimes feels like it has a mind of its own.
This article is the deep dive nobody wrote clearly enough. By the end, you'll be able to look at any piece of async JavaScript and trace — in your head, step by step — exactly what order things will execute and why.
What We'll Cover
- The Single-Threaded Reality
- The Call Stack — JavaScript's Working Memory
- The Web APIs Layer — Where Async Work Actually Happens
- The Callback Queue (Macrotask Queue)
- The Microtask Queue — The Queue That Jumps the Line
- The Event Loop — The Conductor Tying It All Together
-
setTimeoutandsetInterval— What They Actually Promise - Promises and the Microtask Queue
-
async/await— Syntactic Sugar with Real Consequences - Real-World Execution Order Puzzles (With Solutions)
- Pitfalls That Will Bite You in Production
- Conclusion — The Mental Model You'll Keep Forever
1. The Single-Threaded Reality
Let's start with what "single-threaded" actually means, because it's more nuanced than it sounds.
A thread is a sequence of instructions a CPU can execute. Some languages — Java, Go, C++ — are multi-threaded, meaning they can genuinely run multiple instruction sequences simultaneously on different CPU cores. They share memory, they can race each other, and you need mutexes and semaphores and all sorts of painful synchronization primitives to keep them from stepping on each other.
JavaScript deliberately chose not to do that. One thread. No shared memory races. No deadlocks. No mutexes.
But here's the thing people miss: JavaScript is single-threaded, but the browser (or Node.js) is not. The runtime environment — Chrome, Firefox, Node — is heavily multi-threaded. It has threads for network I/O, file I/O, timers, rendering, garbage collection, and more. JavaScript itself runs on one thread, but it delegates slow work to those other threads.
The event loop is the mechanism by which results from those other threads get handed back to your JavaScript code, safely, one at a time.
2. The Call Stack — JavaScript's Working Memory
The call stack is where JavaScript tracks what it's currently executing. It's a stack data structure — last in, first out — and every time you call a function, a new stack frame gets pushed on top. When the function returns, that frame gets popped off.
function greet(name) {
return `Hello, ${name}!`; // 3. This executes, returns
}
function main() {
const message = greet("Fatima"); // 2. greet() is pushed onto stack
console.log(message); // 4. console.log is pushed, executes, pops
}
main(); // 1. main() is pushed onto stack
Execution trace:
[] → [main] → [main, greet] → [main] → [main, console.log] → [main] → []
The call stack is synchronous and blocking. If you put a while(true) loop in there, the stack never clears. Nothing else runs. Your UI freezes. The browser tab hangs.
This is why long-running synchronous operations are the enemy. They hold the stack hostage.
3. The Web APIs Layer — Where Async Work Actually Happens
When you call fetch(), setTimeout(), addEventListener(), or fs.readFile() — you are not running JavaScript. You're calling into the Web APIs layer (in the browser) or the Node.js C++ APIs layer.
Think of it like handing off a task to a dedicated department:
- "Go make this HTTP request. Come back when you have a response."
- "Set a timer for 500ms. Come back when it fires."
- "Watch this DOM element for a click. Come back when it happens."
JavaScript doesn't wait. It just hands off the task, registers a callback, and moves on. The API does the work — off the main thread, in the background — and when it's done, it puts your callback in a queue.
console.log("1 — Starting");
// This call goes to the Timer Web API.
// JavaScript does NOT wait here. It just registers the callback and moves on.
setTimeout(() => {
console.log("3 — Timer fired");
}, 1000);
console.log("2 — Already past the setTimeout");
// Output:
// 1 — Starting
// 2 — Already past the setTimeout
// (1 second later...)
// 3 — Timer fired
JavaScript handed the timer to the browser, said "call me back in 1000ms," and kept running. That's non-blocking I/O in a nutshell.
4. The Callback Queue (Macrotask Queue)
When an async operation completes — a timer fires, a network response arrives, a click event triggers — the callback associated with it gets placed in the callback queue (also called the macrotask queue or task queue).
This queue holds tasks waiting for their turn to run. They can't jump onto the call stack directly. They have to wait.
Common sources of macrotasks:
-
setTimeoutcallbacks -
setIntervalcallbacks - I/O callbacks (file reads, network responses in Node.js)
- UI event handlers (click, keydown, scroll)
-
postMessagecallbacks -
setImmediate(Node.js only)
The queue is processed one task at a time. Each task runs to completion — no interruption. If a task takes 500ms, the browser is locked for 500ms. This is why you'll sometimes see the browser devtools warn about "long tasks."
5. The Microtask Queue — The Queue That Jumps the Line
Here's where most developers' mental models break down.
There are two queues, not one. The second is the microtask queue, and it has priority over the callback queue. Every single time.
Sources of microtasks:
-
Promise.then()/Promise.catch()/Promise.finally()callbacks queueMicrotask()-
MutationObservercallbacks -
await(under the hood, it's a promise)
The rule is this: after every task completes (or after the initial script finishes), the entire microtask queue is drained before the next macrotask runs.
Not one microtask. All of them. And if a microtask schedules another microtask, that one runs too, before any macrotask.
console.log("1 — Script start");
setTimeout(() => console.log("5 — setTimeout"), 0); // Macrotask
Promise.resolve()
.then(() => console.log("3 — Promise 1")) // Microtask
.then(() => console.log("4 — Promise 2")); // Microtask (scheduled by microtask)
console.log("2 — Script end");
// Output:
// 1 — Script start
// 2 — Script end
// 3 — Promise 1
// 4 — Promise 2
// 5 — setTimeout
Even though setTimeout was registered before the Promise chain, it fires after both promise callbacks. The entire microtask queue empties first.
6. The Event Loop — The Conductor Tying It All Together
The event loop is the algorithm that orchestrates all of this. Here it is, in pseudocode:
while (true) {
// 1. Run the current task (or the initial script)
executeCurrentTask();
// 2. Drain the entire microtask queue
while (microtaskQueue.isNotEmpty()) {
microtaskQueue.dequeue().execute();
// Note: if this microtask adds more microtasks, those run too
}
// 3. Maybe render (browser decides, typically ~60fps)
if (renderingNeeded) {
render();
}
// 4. Pick the next macrotask from the callback queue
if (callbackQueue.isNotEmpty()) {
currentTask = callbackQueue.dequeue();
}
}
The loop is always watching. When the call stack is empty and there are tasks waiting, it picks the next one and runs it. But it always drains microtasks first.
Here's the full picture as a diagram:
┌─────────────────────────────────────────────────┐
│ Your JS Code │
│ Call Stack │
└────────────────────┬────────────────────────────┘
│
calls Web APIs / Node APIs
│
▼
┌─────────────────────────────────────────────────┐
│ Web APIs / C++ APIs │
│ (setTimeout, fetch, fs.readFile, events...) │
└──────┬──────────────────────┬───────────────────┘
│ │
▼ ▼
┌─────────────┐ ┌──────────────────┐
│ Microtask │ │ Callback Queue │
│ Queue │ │ (Macrotask Q.) │
│ (Promises) │ │ (setTimeout, │
│ │ │ I/O, events) │
└──────┬──────┘ └────────┬─────────┘
│ │
└──────────┬───────────┘
│
▼
┌──────────────┐
│ Event Loop │ ◄── "Is the stack empty?
│ │ Drain microtasks.
└──────────────┘ Then run next macrotask."
7. setTimeout and setInterval — What They Actually Promise
setTimeout(fn, delay) does not guarantee your callback runs after exactly delay milliseconds. It guarantees the callback will be added to the macrotask queue no sooner than delay milliseconds from now.
If the call stack is busy, the callback waits — no matter how long.
const start = Date.now();
// This timer should fire after 100ms.
setTimeout(() => {
// In reality, this will log something much larger than 100.
console.log(`Fired after ${Date.now() - start}ms`);
}, 100);
// This synchronous loop blocks the call stack for ~500ms.
// The setTimeout callback is in the queue, but it can't run yet.
const blockUntil = Date.now() + 500;
while (Date.now() < blockUntil) {
// spinning — this is exactly the kind of code that freezes UIs
}
// Output: something like "Fired after 502ms" — not 100ms
setTimeout(..., 0) is often used as a trick to defer code to the next iteration of the event loop — but it's still a macrotask, so it yields to all pending microtasks first.
8. Promises and the Microtask Queue
Every .then(), .catch(), and .finally() callback is a microtask. This is baked into the Promise specification — not a browser decision.
console.log("start");
const p = new Promise((resolve) => {
// The executor function runs SYNCHRONOUSLY, right now.
console.log("inside Promise constructor");
resolve("done");
});
p.then((value) => {
// This runs as a MICROTASK — after the current synchronous code finishes.
console.log("then:", value);
});
console.log("end");
// Output:
// start
// inside Promise constructor
// end
// then: done
The Promise constructor runs synchronously. The .then() callback does not — it queues as a microtask and runs after the current call stack empties.
This surprises a lot of developers. They expect the .then() to run right after resolve(). It doesn't. It politely waits its turn.
9. async/await — Syntactic Sugar with Real Consequences
async/await is beautiful syntax. But it's crucial to understand what it compiles to, because the semantics are the same as Promises — just dressed up.
// This async function...
async function fetchUser(id) {
const response = await fetch(`/api/users/${id}`);
const user = await response.json();
return user;
}
// ...is roughly equivalent to this Promise chain:
function fetchUser(id) {
return fetch(`/api/users/${id}`)
.then(response => response.json())
.then(user => user);
}
Every await is a suspension point. When you await something, the async function pauses and hands control back to the caller. The code after the await is scheduled as a microtask to run when the awaited Promise resolves.
async function main() {
console.log("1 — before await");
await Promise.resolve(); // Suspends here. Resumes as microtask.
console.log("3 — after await"); // Runs as microtask
}
main();
console.log("2 — after calling main()");
// Output:
// 1 — before await
// 2 — after calling main()
// 3 — after await
When main() hits the await, it suspends. JavaScript keeps running synchronously past the main() call and logs "2". Then the microtask runs and logs "3".
async/await does not make code run on a different thread. It's still single-threaded. It just makes asynchronous code look synchronous while still yielding the call stack between operations.
10. Real-World Execution Order Puzzles
Let's put it all together. Work through these before peeking at the answers.
Puzzle 1
console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => {
console.log("C");
setTimeout(() => console.log("D"), 0);
});
console.log("E");
Answer
A
E
C
B
D
Why:
-
A— synchronous - setTimeout B → macrotask queue
- Promise → microtask queue
-
E— synchronous - Call stack empty → drain microtasks:
Clogs, setTimeout D → macrotask queue - No more microtasks → run next macrotask:
B - No more microtasks → run next macrotask:
D
Puzzle 2
async function alpha() {
console.log("alpha 1");
await null;
console.log("alpha 2");
}
async function beta() {
console.log("beta 1");
await null;
console.log("beta 2");
}
console.log("start");
alpha();
beta();
console.log("end");
Answer
start
alpha 1
beta 1
end
alpha 2
beta 2
Why:
-
start— sync -
alpha()runs: logsalpha 1, hitsawait, suspends → schedules microtask -
beta()runs: logsbeta 1, hitsawait, suspends → schedules microtask -
end— sync - Call stack empty → drain microtasks:
alpha 2, thenbeta 2
11. Pitfalls That Will Bite You in Production
Starving the render with too many microtasks
Because microtasks all run before the browser gets a chance to render, an infinite microtask loop will lock up the UI just as badly as a synchronous loop — possibly worse, because it looks like async code.
// ❌ Don't do this — infinite microtask loop, browser never renders
function infiniteMicrotasks() {
Promise.resolve().then(infiniteMicrotasks);
}
infiniteMicrotasks();
// ✅ If you need to yield to rendering, use setTimeout or requestAnimationFrame
function yieldToRender(fn) {
requestAnimationFrame(fn); // Runs after the next render frame
}
Unhandled Promise rejections are silent killers
// ❌ This rejection is unhandled. In older Node versions it silently fails.
// In modern Node, it crashes the process.
async function riskyOperation() {
throw new Error("Something went wrong");
}
riskyOperation(); // Missing await AND missing .catch()
// ✅ Always handle rejections
riskyOperation().catch(err => console.error("Caught:", err));
// ✅ Or use try/catch with await
try {
await riskyOperation();
} catch (err) {
console.error("Caught:", err);
}
await inside loops — sequential vs parallel
const userIds = [1, 2, 3, 4, 5];
// ❌ Sequential — each fetch waits for the previous to finish.
// Total time: sum of all request times. Slow.
async function fetchSequential(ids) {
const results = [];
for (const id of ids) {
const user = await fetchUser(id); // Waits here before next iteration
results.push(user);
}
return results;
}
// ✅ Parallel — all requests fire at once.
// Total time: slowest single request. Fast.
async function fetchParallel(ids) {
const promises = ids.map(id => fetchUser(id)); // Fire all, don't await yet
return await Promise.all(promises); // Wait for all to complete
}
The forEach async trap
const data = [1, 2, 3];
// ❌ forEach doesn't await async callbacks. It fires them all and moves on.
// "Done" prints before any of the async work finishes.
data.forEach(async (item) => {
await processItem(item);
});
console.log("Done"); // Prints immediately — not actually done
// ✅ Use for...of when you need to await inside a loop
for (const item of data) {
await processItem(item);
}
console.log("Done"); // Now actually done
12. Conclusion — The Mental Model You'll Keep Forever
Here's the mental model, distilled:
JavaScript has one thread, one call stack. It can only do one thing at a time. Async operations — timers, network calls, I/O — get delegated to the browser/Node runtime, which handles them off the main thread. When they complete, callbacks get queued.
Two queues exist. The microtask queue (Promises, await) and the macrotask queue (setTimeout, I/O, events). After every task — including the initial script — the entire microtask queue drains before the next macrotask runs.
async/await is Promises in a costume. Beautiful, readable, but the same underlying semantics. Every await suspends the function and schedules the rest as a microtask.
Once this model clicks, async JavaScript stops being magic. You can trace any execution order in your head. You know why setTimeout(..., 0) doesn't always mean "immediately." You know why a Promise resolves after your synchronous code. You know why that forEach with await inside was never actually doing what you thought.
The event loop is the heartbeat of JavaScript. Understanding it doesn't just make you better at debugging async bugs — it makes you better at writing async code in the first place. You start structuring things around how JavaScript actually works, rather than how you wish it worked.
Go write something async. Then trace through it mentally. If you get the order right — you've got it.
Further reading: MDN's Concurrency model and the event loop, Jake Archibald's classic talk "In The Loop" (JSConf Asia), and the WHATWG HTML spec on the event loop processing model if you really want to go deep.
Top comments (0)