JavaScript is single-threaded but handles asynchronous operations without blocking through the Event Loop and callback queues. 1) The Call Stack executes functions in order. 2) Web APIs handle async tasks like timers and HTTP requests. 3) Completed async callbacks go to either the Macrotask Queue (e.g., setTimeout) or the Microtask Queue (e.g., Promise.then). 4) The Event Loop checks if the call stack is empty, then prioritizes microtasks over macrotasks. 5) Even with a 0ms delay, setTimeout callbacks wait until the stack and microtask queue are cleared, which is why console.log("2") in a setTimeout runs after Promise.then callbacks despite being queued earlier. This mechanism ensures non-blocking behavior while maintaining execution order predictability.

JavaScript is single-threaded, which means it can only do one thing at a time. But we all know that JavaScript can handle asynchronous operations like setTimeout, HTTP requests, and user interactions — all without freezing the browser. This magic is made possible by the Event Loop and the Callback Queue (also known as the Task Queue). Let’s break it down in simple terms.

How the Event Loop Keeps JavaScript Non-Blocking

When you run JavaScript code, it executes in a specific order. But when asynchronous operations come into play — like setTimeout or fetch — they don’t block the rest of the code. Here’s how:

1. Call Stack – This is where functions are executed. It’s a stack data structure: last in, first out.
2. Web APIs – These are provided by the browser (not part of JavaScript itself) and handle things like timers, HTTP requests, DOM events, etc.
3. Callback Queue (Task Queue) – When an async operation finishes (e.g., a setTimeout timer ends), its callback is placed here, waiting to be executed.
4. Event Loop – This constantly checks if the call stack is empty. If it is, it pushes the first callback from the queue onto the stack.

The key rule: The Event Loop only moves a callback from the queue to the stack when the stack is completely empty.

Example to Illustrate the Flow

console.log("1");

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

console.log("3");

You might expect this to print 1, 2, 3 — but it actually prints:

1
3
2

Here’s why:

• "1" is logged immediately (call stack).
• setTimeout is called — the browser starts a 0ms timer in the Web API.
• "3" is logged next because it’s synchronous.
• Only after the entire main script finishes does the Event Loop check the callback queue.
• The timer completes (almost instantly), so its callback goes to the queue.
• With the stack now empty, the Event Loop picks up the callback and logs "2".

So even with a 0ms delay, the setTimeout callback must wait for the current execution to finish.

Microtasks vs Macrotasks: The Priority Queue

Not all callbacks are treated equally. JavaScript distinguishes between:

• Macrotasks – setTimeout, setInterval, setImmediate, I/O, UI rendering.
• Microtasks – Promise.then/catch/finally, queueMicrotask, MutationObserver.

Microtasks have higher priority. After every macrotask, the event loop runs all microtasks before going back to the macrotask queue.

Example with Promises

console.log("1");

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

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

console.log("4");

Output:

1
4
3
2

Why?

• 1 and 4 log immediately.
• The Promise.then callback goes into the microtask queue.
• After the main script, the Event Loop processes all microtasks — so 3 logs before 2.
• Then it moves to the macrotask queue and logs 2.

This priority system means microtasks can delay macrotasks, which is important for performance and predictability.

Key Takeaways

• JavaScript is single-threaded, but the browser’s Web APIs handle async operations behind the scenes.
• The Event Loop monitors the call stack and the callback queues.
• Callbacks from setTimeout, setInterval, and similar go to the macrotask queue.
• Promises and queueMicrotask go to the microtask queue, which is processed before the next macrotask.
• Nothing in the callback queues runs until the call stack is empty.

Understanding this flow helps explain why async code behaves the way it does — and why you can’t truly "pause" JavaScript with setTimeout(..., 0).

Basically, it’s not magic — it’s the Event Loop doing its job.

The above is the detailed content of Understanding the JavaScript Event Loop and Callback Queue. For more information, please follow other related articles on the PHP Chinese website!