The event loop and the job queue

JavaScript runs your code on a single thread. There is one worker, and the worker does one thing at a time. That is not a limitation somebody forgot to fix — it is the deal that means you never have to worry about two parts of your program changing the same variable at the same instant.

The worker keeps a stack of what it is currently doing, called the call stack. Calling a function pushes a new sheet on top of the pile: this function, its arguments, its local variables, and the line to return to. When the function returns, the sheet is thrown away and the worker carries on with the sheet underneath.

So at any moment the stack tells you the whole story of "how did we get here". That is exactly what you are reading when a stack trace appears in an error message: the pile of unfinished calls, most recent at the top.

Picture a kitchen with exactly one chef. The chef can only do one action at a time — chop, stir, plate. But the kitchen also has an oven with a timer, a kettle, and a hatch where deliveries arrive.

The chef puts a tray in the oven and sets the timer. They do not stand and watch it. They go back to chopping. When the timer pings, they finish the chop they are on — they never abandon it half-way — and then deal with the oven.

Everything about asynchronous JavaScript is in that picture. The oven, kettle and hatch are the host environment: timers, network requests, file reads. They do their waiting elsewhere. The chef is your single thread, and the pings pile up in a queue until the chef is free. Nothing ever interrupts the chef mid-chop.

"Never abandon a chop half-way" has a name: run to completion. Once a piece of JavaScript starts, it runs all the way to the end before anything else gets a turn. No timer, no click handler and no promise callback can cut in halfway through your function.

This is why the ordering rules in this module are learnable at all. You only need to ask what happens between pieces of code, never inside one. And it is why the shared-state bugs that plague threaded languages mostly do not exist here — while your function runs, nothing else can touch what it is touching.

The bill for that guarantee arrives in the next section: if nothing can interrupt you, then a slow piece of code holds everything up.

When the stack empties, the worker looks for queued work. There are two queues, and the difference between them decides almost every ordering puzzle you will meet.

The task queue (older material calls these macrotasks) holds things like timer callbacks and event handlers. One task is taken and run to completion per turn of the loop.

The microtask queue holds jobs — and promise reactions are jobs. MDN's definition is precise: a microtask runs after the function or program that created it exits, only when the JavaScript stack is empty, and before control goes back to the event loop. The crucial extra rule is that the microtask queue is drained until it is empty, so a microtask that queues another microtask gets it run before the next task, not after.

That gives the ordering you will see quoted everywhere: all of the current synchronous code, then every pending microtask, then one task, then microtasks again, and so on. A `.then` callback beats a `setTimeout(..., 0)` callback every time, even though the timer asked for zero delay.

1. Run the current piece of code, top to bottom, to completion. Anything asynchronous it starts is handed to the host and simply booked; nothing waits.

2. The stack is now empty. Drain the microtask queue completely, running each job to completion. If those jobs queue more microtasks, drain those too.

3. Take one task from the task queue and run it to completion.

4. Drain the microtask queue again.

5. Repeat from step 3, forever.

Keep this list next to any ordering question and answer it mechanically. Where does this callback go — microtask queue or task queue? Is the stack empty yet? That is the whole method, and it beats intuition every time.

"Asynchronous means it runs in the background at the same time." Your JavaScript never runs at the same time as your other JavaScript. What happens elsewhere is the waiting — the operating system watching a socket, the browser counting down a timer. When the answer is ready your callback joins a queue and waits for its turn on the one thread.

"`setTimeout(fn, 0)` runs `fn` immediately." It queues a task. Every pending microtask runs first, and the current code has to finish first as well. The number is a minimum delay before it becomes eligible, never a promise about when.

"The event loop is part of JavaScript." It is not. ECMAScript, the language standard, defines jobs and leaves the scheduling to whoever is hosting it; browsers define their event loop in the HTML standard, and Node.js defines its own. This is why the same promise ordering rules hold everywhere but timer behaviour differs between a browser and a server.

Run-to-completion plus one thread means that a function that takes 300 ms freezes everything for 300 ms. In a browser that is 300 ms with no scrolling, no typing, no clicking, and no animation — the page looks broken, because as far as the user can tell it is.

This is the practical reason asynchronous code exists. Not elegance: a running program that stays responsive. Any operation that involves waiting for something outside the program — a server, a disk, a person — is handed off so the thread stays free.

It also tells you what asynchronous code cannot fix. If your code is slow because it is doing a million calculations, wrapping it in a promise changes nothing: the calculations still occupy the one thread. Asynchronous helps with waiting, not with working.

One thread, one call stack, and every piece of code runs to completion. Waiting happens outside your code; finished work comes back as queued callbacks. Microtasks (promise jobs) drain completely before the next task, so `.then` beats `setTimeout(..., 0)`. The event loop belongs to the host, not to the language. And because nothing can interrupt you, slow synchronous code freezes the lot.