JavaScript's event loop ensures that asynchronous operations are executed in an orderly manner. The answer is: 1. Execute synchronous code first; 2. Asynchronous tasks are processed by the Web API and entered the corresponding queue; 3. The event loop prioritizes the micro-task queue and then executes macro tasks. Therefore, the code first outputs synchronous content, then executes micro-tasks such as Promise.then, and finally handles macro-tasks such as setTimeout, forming a specific output sequence, and the complete process continues to schedule the tasks in a closed-loop manner until they are finished.

The JavaScript event loop is often misunderstood because it's invisible — you can't see it running — but it's the backbone of how JavaScript handles asynchronous operations while staying single-threaded. Let's break it down visually and simply, so you can see what's really happening behind the scenes.

? How JavaScript Runs Code: The Call Stack

Imagine a to-do list where JavaScript keeps track of functions to run. This is the call stack .

 function greet() {
  console.log("Hello");
}
greet();

When greet() is called, it's added to the stack. After it runs, it's removed. Simple.

Now, what happens when you have something asynchronous, like:

 console.log("Start");
setTimeout(() => console.log("Timeout"), 0);
console.log("End");

You'd expect:

 Start
Timeout
End

But you actually get:

 Start
End
Timeout

Why? Because JavaScript doesn't just have a call stack — it has other parts working behind the scenes.

? The Three Key Players

Think of JavaScript's runtime like a small office with three workers:

1. Call Stack – The worker actively doing tasks (executing functions).
2. Callback Queue (Task Queue) – A waiting line for tasks that are ready to be processed (eg, setTimeout , fetch responses).
3. Event Loop – The manager that checks: “Is the call stack empty? Can I move something from the queue?”

And don't forget:

• Web APIs – Not part of JavaScript, but built into the browser (or Node.js). They handle things like setTimeout , DOM events, HTTP requests, etc.

?? Visual Walkthrough: What Happens in setTimeout

Let's step through this code:

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

Here's what happens behind the scenes:

1. console.log("A") → added to call stack → runs immediately → prints "A"
2. setTimeout(...) → added to stack
   • The browser sees this and says: “I'll handle the timer”
   • It starts a 0ms timer via Web API
   • setTimeout is removed from the stack
3. console.log("C") → runs → prints "C"
4. The timer finishes instantly (0ms), but the callback () => console.log("B") can't run yet
   • It's sent to the Callback Queue
5. The Event Loop checks: Is the call stack empty?
   • Yes! Nothing is running now.
   • So it moves the callback from the queue to the call stack
6. console.log("B") runs → prints "B"

So order: A → C → B

?? Microtasks vs Macrotasks: A Deeper Layer

Not all async tasks are equal. There are two queues:

• Macrotask Queue : setTimeout , setInterval , setImmediate , I/O, UI rendering
• Microtask Queue : Promise.then/catch/finally , queueMicrotask , MutationObserver

? The event loop gives microtasks priority . After every macrotask, it runs all microtasks before going back to the macrotask queue.

Example:

 console.log("1");

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

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

console.log("5");

Output:

 1
5
3
4
2

Why?

• 1 and 5 run sync.
• setTimeout → goes to macrotask queue
• Promises → go to microtask queue
• After the main script, event loop:
  • Sees microtasks: runs all (3, then 4)
  • Then checks macrotasks: runs 2

This is critical — microtasks run before the next render or setTimeout .

? Event Loop in a Loop (Pseudocode Style)

You can think of the event loop like this infinite loop:

 while (true) {
  if (callStack.isEmpty()) {
    const microtask = microtaskQueue.pop();
    if (microtask) {
      run(microtask);
    } else {
      const task = macrotaskQueue.pop();
      if (task) {
        run(task);
      }
    }
  }
}

Key rule: Run all microtasks after each macrotask .

? Why This Matters

Understanding the event loop helps you:

• Debug why async code doesn't run in the order you expect
• Avoid blocking the main thread (eg, long loops freeze the UI)
• Use queueMicrotask or Promise hacks when you need something to run right after current code
• Know why setTimeout(fn, 0) isn't truly “immediate”

? Summary (Visual Recap)

Imagine this flow:

 [Call Stack] ← Event Loop ← [Microtask Queue]
                ↑
          [Macrotask Queue]
                ↑
         [Web APIs (Browser)]

1. Sync code runs → call stack
2. Async stuff → offloaded to Web API
3. When ready → goes to queue (micro or macro)
4. Event loop waits for stack to clear
5. Microtasks first, then one macrotask at a time

Basically, the event loop is JavaScript's way of multitasking without threads — by cleverly managing what runs when. Once you see it as a loop that shuttles callbacks from queues to the stack, the “magic” becomes clear.

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