async/await, desugared

async/await is a generator plus a driver

async/await is pure syntax sugar; the engine desugars it to a coroutine. An async function is, mechanically, a generator whose yield points are the awaits, paired with an automatic driver that advances the generator each time an awaited value settles. Two facts fall out immediately:

1. An async function always returns a promise. Calling it runs the body synchronously up to the first await, then returns a pending promise representing “the eventual completion of this function.” A return x inside fulfils that promise with x; a thrown error rejects it.
2. await x is a suspension point. When control hits await x, the engine: wraps x via PromiseResolve (turning any value or thenable into a promise to subscribe to), registers a continuation as a reaction on that promise, and returns from the function — yielding the thread back to the host. When the awaited promise settles, the registered reaction (a microtask) resumes the function right after the await, with the value substituted in (or rethrowing the rejection).

Because resuming is a microtask, an async function with two awaits is not one synchronous unit — it is sliced into pieces that interleave with every other pending microtask between resumptions. This is the lens for the lesson: await is a yield to a driver, and the driver runs on the microtask queue.

The history: await used to cost three ticks

The original ES2017 spec for await was wasteful. To handle the case where you await a thenable, the spec said: take the operand, create a brand-new throwaway promise, resolve that with the operand, then .then onto it to subscribe. Even when the operand was already a native promise, you paid for the throwaway promise and its thenable-adoption job. The cost, measured in microtask ticks before the function resumed, was about three ticks for await p where p is a native promise — versus one tick for the equivalent p.then(...). In a hot loop full of awaits, this tripled the microtask traffic.

// Before V8 7.2, `await p` was roughly equivalent to:
const throwaway = new Promise(resolve => resolve(p)); // adopt p — extra ticks
throwaway.then(resume);                                // subscribe — another tick
// ≈ 3 microtask ticks to resume, even for a native promise p

V8 7.2 (2018): await ≈ p.then

V8 7.2 shipped the await optimization. When the awaited operand is a native promise (a genuine Promise, not a foreign thenable), the engine skips the throwaway-promise dance entirely and registers the resume reaction directly on the operand — exactly as p.then(resume) would. That collapses await p from ~3 ticks to 1 tick, matching hand-written .then. TC39 then changed the spec itself to match (the --harmony-await-optimization flag gated it during rollout; it is now the default and the spec behaviour). The practical upshot for seniors: since late-2018 engines, you no longer pay a tick tax for using await over .then on native promises — write whichever reads clearer. The tax only returns if you await a non-native thenable, which still needs the adoption job.

Zero-cost async stack traces

The same release era brought zero-cost async stack traces. The problem: when an error surfaces three awaits deep, the synchronous call stack is long gone — each await returned to the host, so a naive trace shows only the innermost resumption with no caller chain. The old fix (kept under a flag) recorded a stack on every promise creation, which was expensive in hot paths. The zero-cost approach instead reconstructs the async frames on demand from the promise chain: V8 walks the [[PromiseFulfillReactions]] links (from lesson 3) backwards to rebuild the logical async call stack only when DevTools actually asks for it (when you hit a breakpoint or read error.stack in a debugging context). The fast path pays nothing — no per-await allocation — yet you still get a full async trace in the debugger. “Zero-cost” means zero cost when you are not debugging.

Error propagation: a rejection becomes a throw

When you wrap an await in try/catch and it actually catches the network error, you might wonder: how does an asynchronous rejection land in a synchronous catch block? Because the resume reaction is registered for both fulfilment and rejection, await converts an asynchronous rejection back into a synchronous-looking throw inside the function. When the awaited promise rejects, the engine resumes the function by throwing the rejection reason at the await expression — so a try/catch around the await catches it exactly as if a synchronous function had thrown. This is the entire ergonomic win of async/await: linear error handling over inherently non-linear control flow. The flip side is the trap from lesson 3 — an unawaited, uncaught rejected promise triggers unhandledrejection, because no reaction was registered to convert it into a catchable throw.