The Event Loop, Visualized

fetch — a real network wait — interactive event loop example

1console.log('requesting');
2 
3fetch('/api/user')
4  .then((res) => res.json())
5  .then((user) => {
6    console.log('got', user.name);
7  });
8 
9console.log('not waiting');

The script starts on the call stack. console.log("requesting") runs synchronously.

1 / 9

Call stack

script

Web APIs — browser land

The event loop — is the call stack empty? → drain the microtask queue first → then take one callback.

Microtask queue — priority

Callback queue

Console

01requesting

Fig. — fetch — a real network wait · step 1 of 9

What is going on here

fetch is the clearest demonstration of why the event loop exists. The network takes tens or hundreds of milliseconds, and the main thread spends none of it waiting. The request is handed to the browser, the stack empties, and the page stays responsive to clicks and animation the whole time.

The detail worth internalising is where the callback lands when the response comes back. A timer callback is queued as a task; a resolved promise queues a microtask. fetch settles a promise, so its .then callbacks are microtasks — they run before any setTimeout callback that has been waiting, even one that expired long before the response arrived.

The two-step chain is also not an accident of style. fetch resolves as soon as response headers arrive, before the body has been read; res.json() reads and parses the body and returns another promise. That is why the idiomatic shape is two .then links, and why each link costs its own microtask — though all of them drain in a single checkpoint, with no task allowed in between.

Common questions

Is fetch a macrotask or a microtask?

Neither — the network request itself runs outside JavaScript entirely. When it completes it resolves a promise, and promise reactions are microtasks, so your .then callback runs on the microtask queue ahead of any pending setTimeout callback.

Why does fetch need two .then calls?

The first promise resolves as soon as response headers arrive, giving you a Response object. Reading the body is a separate asynchronous step, so res.json() returns another promise, which the second .then unwraps.

Does an await on fetch block the page?

No. await suspends only the async function that contains it; the call stack unwinds and the event loop keeps processing clicks, timers and rendering. Blocking the page requires a synchronous loop that never returns to the loop.

Every question on one page →·Run your own code →

Embed this figure in your own post →

Drop this into any article or course page. It stays interactive — readers can step through it without leaving your site.