One await is a suspended stack frame, a queued microtask, a drained checkpoint — and only then a resumed function.

When a function is created, the engine stores a reference to the current environment record in the function's internal [[Environment]] slot. If the function outlives the call that created it, that environment record survives too — the variables inside it are not copied, not snapshotted, not garbage collected. They stay live, and every call to the function reads and writes the same records.

Popular teaching material calls this the function's "backpack" or COVE ("closed-over variable environment"). Those are excellent nicknames — but nicknames. The spec mechanism is the [[Environment]] chain, and the real name is worth having, because every construct in the rest of this document is a use of it. An iterator's position, a generator's locals, an async function's variables across an await — all of them live in environment records that stay reachable when no frame is on the stack.

The iterator protocol is minimal: an object with a next() method that returns an IteratorResult — { value, done }. The traversal position is private state closed over by next(). The iterable protocol is one level up: an object with a Symbol.iterator method that produces an iterator. for…of, spread, destructuring and Array.from are all consumers of that handshake.

The key is registered under a well-known symbol rather than a string so the protocol can be bolted onto any object — including ones that already have a next property for their own reasons — with zero chance of collision.

Calling a generator function runs none of its body. It allocates a generator object — implementing both protocols above — whose internal [[GeneratorState]] starts as suspendedStart. Each next() pushes the function's frame back onto the stack and runs until the next yield; each yield pops the frame without destroying it — locals, position, even the half-evaluated expression survive in the object on the heap.

yield is a two-way valve: the operand goes out as { value, done: false }, and the argument of the resuming next(v) comes in as the value the paused yield expression evaluates to. (The very first next() starts the body, so its argument has no paused yield to land in — it is discarded.)

Under the API, a promise is small. Three internal slots: a state (pending → exactly one of fulfilled / rejected, forever), a settled value, and a list of PromiseReaction records appended by every .then/.catch/.finally. Two rules do all the work. First: the executor you pass to new Promise(…) runs synchronously, immediately. Second: reactions never run synchronously, even if the promise is already settled. Settling doesn't call your handlers — it hands each reaction to HostEnqueuePromiseJob, which puts a PromiseReactionJob on the microtask queue.

That second rule is the sanity contract of async JavaScript: code after .then(fn) always runs before fn, whether the promise settles in a microsecond or a minute. No "sometimes sync, sometimes async" — the footgun that plagued callback libraries (Zalgo) is banned by the spec.

Take the generator's pause valve from section 04 and the promise's reaction list from section 05, and you can write await yourself in a 10-line runner. Pull a value from the generator. Wrap it with PromiseResolve so plain values and thenables behave alike. Attach a .then that feeds the settled result back in through next(v). Repeat until done. That runner is the semantics of an async function — the engine implements it directly with its own machinery rather than literally rewriting your code into a generator, but every observable behaviour matches.

Every structure in the last two sections had two lanes, and we have only driven one. A PromiseReaction records two handlers. The runner above passes two callbacks to .then. Follow the second one and the whole error story falls out. A throw anywhere inside an async function — the synchronous section included — never escapes at the call site; it rejects the promise the call already returned. An await whose operand rejects rethrows that rejection at the await expression, inside your frame, where an ordinary try/catch is standing. And a rejection still unobserved when the microtask queue drains becomes an unhandled rejection — an event, not a warning.

await fused the suspension machinery with the promise machinery to wait for one future value. An async generator function — async function* — performs the same fusion in the other direction: it produces a whole sequence of future values, and hands them out one pull at a time. Calling it still runs no body code. It returns an async generator object implementing the async iteration protocols from section 01 — the same { value, done } shape, one promise later: every next() returns a Promise of an IteratorResult.

Two details carry all the semantics. First, yield v in an async generator awaits its operand before emitting — the consumer always receives the settled value, never a promise inside value. Second, the body cannot be re-entered, so calls made while it is running are not errors and not interleavings: each next() / return() / throw() becomes an AsyncGeneratorRequest in an internal queue, and the machine resumes the body once per request, in order. Call next() three times synchronously and you hold three pending promises that will settle strictly in sequence.

The event loop is a scheduler with an asymmetry at its heart. Tasks (timers, I/O, events, script execution) are taken one per turn, oldest first from a chosen task source. Then comes a microtask checkpoint: the microtask queue is drained to empty — including microtasks enqueued while draining. Only then may the browser render, and only then does the next task run. Promise reactions and await resumptions are microtasks; that is why they beat every waiting setTimeout, always. Node keeps the same contract on a different chassis — flip the ⇄ chassis toggle on the figure to watch libuv turn the identical asymmetry through its phases.