Explain the JavaScript event loop

JavaScript runs your code on a single call stack, but the browser or Node runtime handles timers, network requests and input in the background. The event loop decides when their callbacks get to run.

The three queues that matter

• Call stack: synchronous code currently executing
• Microtask queue: promise reactions, queueMicrotask(), MutationObserver
• Task queue: setTimeout, setInterval, I/O callbacks, UI events

After every task, the runtime drains the entire microtask queue before taking the next task. That ordering is the point interviewers are testing.

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => console.log("C"));

console.log("D");

// A, D, C, B

await uses the same microtask queue. Code after an await is a promise reaction, so it resumes before the next timer.

async function run() {
  console.log("1");
  await Promise.resolve();
  console.log("2");
}

console.log("0");
run();
console.log("3");

// 0, 1, 3, 2

Why it matters

• Long synchronous work blocks input, timers and rendering. Split it or move it to a worker.
• A chain of resolved promises can starve rendering if it never yields to a task.
• setTimeout(fn, 0) means "next task", not "immediately".
• requestAnimationFrame runs before paint, as part of the browser's rendering steps.