Rethinking the Event Loop: 8 Examples That Shift Your Perspective

Most of us learn the JavaScript event loop in one line:

• Call stack runs sync code first
• Then microtasks (Promise.then, queueMicrotask)
• Then macrotasks (setTimeout, setInterval, I/O callbacks)

That is correct, but not enough for real debugging.

These 8 examples are small, but each one fixes a common mental model mistake.

A quick personal note: in several frontend interview loops, I kept getting the same style of question: “guess the output” for async JavaScript snippets. At first, I treated them like trick questions. Over time, those rounds forced me to build a precise event loop mental model, and that changed how I debug async bugs in real projects too.

1) finally() ordering is still microtask-driven

1
console.log("1");
2

3
Promise.resolve()
4
  .then(() => console.log("2"))
5
  .finally(() => console.log("3"))
6
  .then(() => console.log("4"));
7

8
console.log("5");

Output:

1
1
2
5
3
2
4
3
5
4

Why:

• 1 and 5 are synchronous.
• .then, .finally, next .then are queued in promise chain order.
• finally runs after previous settlement and before next chained then.

2) Promise executor is synchronous, .then is not

1
console.log(1)
2

3
setTimeout(() => console.log(5), 0)
4

5
let promise = new Promise((resolve) => {
6
  console.log(7)
7
  resolve(8)
8
})
9

10
promise.then((value) => console.log(value))
11

12
console.log(3)

Output:

1
1
2
7
3
3
4
8
5
5

Why:

• The new Promise(...) executor runs immediately, so 7 is sync.
• .then callback (8) is a microtask.
• setTimeout callback (5) is a macrotask.

3) Async/await trap: await splits execution

1
console.log("A");
2

3
async function foo() {
4
  console.log("B");
5
  await Promise.resolve();
6
  console.log("C");
7
}
8

9
foo();
10

11
console.log("D");

Output:

1
A
2
B
3
D
4
C

Why:

• foo() starts synchronously, so B logs immediately.
• await pauses the function and schedules continuation (C) as a microtask.
• Main thread continues with D first.

4) await with normal value still defers

1
console.log("1");
2

3
async function test() {
4
  console.log("2");
5
  await 10;
6
  console.log("3");
7
}
8

9
test();
10
console.log("4");

Output:

1
1
2
2
3
4
4
3

Why:

• await 10 is effectively await Promise.resolve(10).
• Even non-promise values cause async function continuation in microtask phase.

5) Microtask created inside microtask

1
console.log("start");
2

3
Promise.resolve().then(() => {
4
  console.log("p1");
5
  queueMicrotask(() => {
6
    console.log("qm");
7
  });
8
});
9

10
Promise.resolve().then(() => {
11
  console.log("p2");
12
});
13

14
console.log("end");

Output:

1
start
2
end
3
p1
4
p2
5
qm

Why:

• Initial microtask queue has p1, then p2.
• While running p1, we add qm to the end of microtask queue.
• So p2 runs before qm.

6) queueMicrotask and promise callbacks share the same microtask queue

1
console.log("A");
2

3
queueMicrotask(() => console.log("B"));
4

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

7
console.log("D");

Output:

1
A
2
D
3
B
4
C

Why:

• Both are microtasks.
• FIFO ordering decides sequence.
• queueMicrotask is scheduled first here, so B before C.

7) return inside .then passes value to next link

1
Promise.resolve()
2
  .then(() => {
3
    console.log("A");
4
    return "B";
5
  })
6
  .then((val) => {
7
    console.log(val);
8
  });
9

10
console.log("C");

Output:

1
C
2
A
3
B

Why:

• Outer sync console.log("C") runs first.
• First .then runs in microtask, returns "B".
• Returned value resolves the next .then, which logs B.

8) setTimeout(fn, 0) is not “run immediately”

1
console.log("1");
2

3
setTimeout(() => console.log("2"), 0);
4
for (let i = 0; i < 100000000; i++) {}
5
setTimeout(() => console.log("3"), 0);
6
setTimeout(() => console.log("4"), 0);
7
console.log("3");

Output:

1
1
2
3
3
2
4
3
5
4

Why:

• Timers are macrotasks and can only run after current synchronous work finishes.
• The heavy loop blocks the thread, delaying all timers.
• Zero delay means “eligible soon,” not “instant.”

A practical model you can use while debugging

When output surprises you, check in this order:

1. What runs synchronously right now?
2. Which callbacks are microtasks?
3. Which callbacks are macrotasks?
4. Did any running microtask enqueue more microtasks?
5. Is any long sync work delaying the next task turn?

If you follow this checklist, event loop questions become deterministic instead of guesswork.

Final takeaway

The event loop is less about memorizing definitions and more about understanding queue priority and enqueue timing.

Once that clicks, tricky async code starts feeling predictable.