Rewrite this async function as an equivalent promise chain and say what the rewrite reveals about `await`: `async function load(id) { const user = await fetchUser(id); const posts = await fetchPosts(user.id); return { user, posts }; }`

## The mechanical rewrite ```js function load(id) { return fetchUser(id).then(user => fetchPosts(user.id).then(posts => ({ user, posts })) ); } ``` A more literal transform also guards the synchronous prefix, because an async function turns a synchronous throw into a rejection: ```js function load(id) { try { return fetchUser(id).then(/* ... as above ... */); } catch (e) { return Promise.reject(e); // what `async` does for free } } ``` ## What each piece of the sugar maps to - **`async` on the declaration** → the function is guaranteed to return a promise, and any synchronous throw becomes a rejection of it. - **`await X`** → `Promise.resolve(X).then(continuation)`. `X` is resolved (so a non-promise or a thenable both work), and *everything textually after the await* becomes the continuation. - **the value of the `await` expression** → the parameter of that continuation callback. - **`return value`** → the value returned from the innermost callback, which the surrounding chain resolves with — including thenable adoption, so returning a promise does not nest. The single most useful sentence to say out loud is: **await is a cut point.** The function is scissored at each `await`, and the tail becomes a callback. ## Why the naive rewrite nests In the async version, `user` is an ordinary local variable that is still in scope on the last line. In a chain, each `.then` callback is a separate function with its own scope, so a later step can only see an earlier value if it is lexically inside that step's callback, or if you thread it through explicitly: ```js // flat, but you must carry the value yourself function load(id) { let user; return fetchUser(id) .then(u => { user = u; return fetchPosts(u.id); }) .then(posts => ({ user, posts })); } ``` That carrying — a mutable outer variable or an ever-growing tuple passed down the chain — is precisely the ceremony `async`/`await` removes, and it is the answer to "why bother with await if it is just `.then`". ## Where the model stops being literal The chain is observationally equivalent for straight-line code, but the engine does not rewrite your function into callbacks. It compiles it into a resumable frame — a state machine that remembers where it stopped. That difference is visible in several places: - **Control flow spanning awaits.** `try { const a = await p; } finally { cleanup(); }` keeps one lexical block across the suspension. A callback rewrite has to re-create that with `.finally` and careful reordering. - **Loops.** `for (const id of ids) { results.push(await fetchUser(id)); }` has no fixed-length chain equivalent, because the number of steps is not known statically. Hand-desugaring needs recursion or a `reduce` over a promise accumulator. - **Locals, `this`, and closures.** All survive the suspension unchanged, because it is one frame, not several separate callback scopes. - **Stack traces.** Engines reconstruct an async stack across suspension points; a hand-written chain gives you the callback's stack and usually less context. - **Scheduling detail.** The exact number of queued steps between the awaited value settling and the function resuming is not identical between the two forms. That is a question about job scheduling, not about the sugar, and it is why you should describe the rewrite as *equivalent in outcome*. ## How to answer this in an interview Write the chain, then say the three things it proves: the returned promise is created by the wrapper, not by the body; `await` is resolve-plus-continuation; and the return value goes through promise resolution, which is why returning a promise flattens. Then volunteer the limit of the model — loops and `try`/`finally` — because that is the part that shows you know it is a state machine and not a macro.