The engine vs the loop

The engine does not have an event loop

The browser overview lessons treat the event loop as one machine — browser/01-event-loop/01-loop-model is the runtime view. This unit is the engine view, and the first correction is structural: the engine has no event loop. ECMAScript, the language V8 implements, never mentions one. The spec defines jobs and a job queue, and it says hosts must eventually run queued jobs — but the algorithm that decides when and which task to run next is explicitly left to the host (via the HOST hooks HostEnqueuePromiseJob, HostCallJobCallback).

So the division of labour is:

• The host (Chromium’s message loop, Node plus libuv, Deno, Bun) owns the loop. It holds the macrotask queues (timers, I/O completions, message events), it decides which task runs next, and it drives rendering. It is the while (true) at the top.
• The engine (V8) owns one queue — the microtask queue (the ECMAScript “jobs queue”) — and exposes one operation to drain it: PerformMicrotaskCheckpoint. It runs the JavaScript the host hands it, to completion, and on the way out it drains its own microtasks.

Together, host and engine interlock so precisely that async ordering stops feeling like folklore and starts feeling inevitable — get this split clear once and every subsequent async surprise has a mechanical explanation.

When people say “the event loop,” they mean the host loop. When they say “microtasks run after the current task,” they mean the engine’s checkpoint. Conflating the two is why async ordering feels like folklore instead of mechanism.

The shape of one turn: host calls in, engine returns, microtasks drain

A single turn of the host loop is a call into the engine and a return out of it. The host picks one macrotask (say, a fired click event or an expired timer), and calls into the engine on the associated JavaScript callback. The engine pushes a stack frame, runs your code to completion — JavaScript is run-to-completion, there is no pre-emption mid-function — and when the call stack empties, the engine performs a microtask checkpoint: it drains every queued microtask (Promise reactions, queueMicrotask jobs) until the queue is empty, including microtasks that other microtasks enqueued. Only then does control return to the host, which renders (in the browser) and picks the next macrotask.

The crucial detail: the microtask drain happens inside the single host-to-engine call, before the engine returns. From the host’s point of view, running the click handler and running every promise reaction it scheduled is one indivisible task. That is why microtasks always run before the next timer, before the next render, before the next anything: they are not a separate task the host schedules — they are the tail of the task that is already running.

Who provides the checkpoint, and who calls it

PerformMicrotaskCheckpoint is V8’s; the decision to call it is partly shared. V8 will auto-run microtasks when the JS call stack empties (the default “auto” microtask policy used by the browser). Node uses an explicit policy: libuv runs a phase, and Node calls runMicrotasks() itself at well-defined points (after each macrotask callback, and between phases) — which is why Node’s ordering has its own rules we cover next lesson. Either way, the queue and the drain are the engine’s; the cadence is the host’s.

Run-to-completion is the load-bearing rule

Everything above rests on one engine guarantee: run-to-completion. Once the host hands the engine a callback, that callback runs start-to-finish with no other JavaScript interleaving. No second task, no microtask, nothing pre-empts it. This is what makes a for loop atomic from the program’s view and what makes await (next lessons) need an explicit suspension mechanism — the engine cannot just “pause” a function the way an OS pauses a thread, because run-to-completion forbids it. The function must return to the host, and a microtask must resume it later.