Lesson 4 of 80

The Event Loop & Async

Q: JavaScript is single-threaded. So how does it handle asynchronous work like timers and fetches without blocking?

A strong answer covers: One call stack; async work is offloaded and its callback queued; The event loop runs a queued callback when the stack is empty; Distinguishes microtasks (promises) from macrotasks (timers/IO), microtasks first.

How single-threaded JavaScript does many things at once — the call stack, the queues, and why setTimeout(0) still waits.

16 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

What does setTimeout(fn, 0) actually promise about when fn runs?

fn runs after the stack clears and microtasks drain — 0 is a minimum, not 'now'fn runs synchronously on the next linefn runs exactly 0 milliseconds later

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on The Event Loop & Async

What interviewers actually ask about this, and what a strong answer has to cover.

JavaScript is single-threaded. So how does it handle asynchronous work like timers and fetches without blocking?

A strong answer covers

One call stack; async work is offloaded and its callback queued
The event loop runs a queued callback when the stack is empty
Distinguishes microtasks (promises) from macrotasks (timers/IO), microtasks first

Likely follow-ups

You mentioned a queue — is there actually more than one? Which drains first?
So where does async/await fit — is it a new mechanism or built on something you already named?
Could microtasks ever prevent a timer or a UI repaint from ever running? How?

Practice these with the AI interviewer →

The plain-language idea

JavaScript runs on one thread — it can only do one thing at a time. So how does it handle timers, clicks, and network calls without freezing?

It parks them. When something async finishes, its callback waits in a queue. The event loop is the doorman: whenever the main call stack is empty, it lets the next waiting callback in.

Two queues, not one

There are two lines, and one has priority:

Microtasks — promise callbacks (.then, await continuations). Highest priority.
Macrotasks — timers (setTimeout), I/O, UI events.

The rule: after each macrotask, JavaScript drains the entire microtask queue before touching the next macrotask.

console.log("1");
setTimeout(() => console.log("2 (timer)"), 0);
Promise.resolve().then(() => console.log("3 (promise)"));
console.log("4");
// order: 1, 4, 3 (promise), 2 (timer)

Even though the timer is set to 0, the promise runs first — microtasks jump the queue.

The event loop: who goes firstStep 1 of 5

Your code runs on the call stack. Along the way it schedules two things.

What people usually miss

Watch out

async/await is promises underneath. The code after an await is a microtask continuation — not magic threading.
Microtasks can starve the UI. A promise that keeps scheduling more promises never lets a macrotask (or a repaint) through.
setTimeout delay is a minimum, not a guarantee. The callback runs no sooner than the delay, once the loop gets to it.

Why this matters in interviews

"What logs first — a setTimeout(0) or a resolved Promise.then?" is a rite of passage. Getting it right, and explaining microtasks vs macrotasks, signals you actually understand async, not just await.