In JavaScript, does `const a = await getA(); const b = await getB();` take the same total time as `const pa = getA(); const pb = getB(); const a = await pa; const b = await pb;`? Explain what makes them differ.

## A promise is work that has already started The single most useful mental correction here is that a promise is not a recipe you can choose to run later — it is a receipt for work that is already underway. Calling `getA()` runs the function body; if it is an `async` function, the body executes synchronously up to its first `await`, and by then the underlying request has usually been issued. The promise handed back is just the channel on which the eventual result will arrive. That makes `await` a *consumption* operation, not a *start* operation. It says "suspend this function and resume it when that promise settles". Nothing about it triggers the work. ## The two shapes side by side ```js // Version 1 — serialized: total ≈ tA + tB const a = await getA(); const b = await getB(); // this line has not run yet while A is in flight // Version 2 — overlapped: total ≈ max(tA, tB) const pa = getA(); // starts now const pb = getB(); // starts now, alongside A const a = await pa; const b = await pb; ``` In version 1, `getB()` is a sub-expression of the second statement. Statements run in order, and the second statement is part of the continuation scheduled when `pa` settles — so B literally cannot begin until A has finished. In version 2, both calls are evaluated before the function ever suspends, so both operations run during the same wall-clock window. The sequential-looking pair of awaits at the end of version 2 confuses people, and it is worth being explicit: awaiting `pa` and then `pb` is *not* serialization. If B takes 300 ms and A takes 100 ms, `await pa` resumes at 100 ms and `await pb` then resumes at 300 ms — total 300 ms, not 400 ms. If B finishes *first*, `await pb` returns immediately when execution reaches it, because settled promises resume their awaiters on the very next microtask. The order in which you consume the results has no effect on total elapsed time. ## Why this shows up as a real bug Code that looks like a straightforward sequence of steps is the natural way to write things, and each individual `await` looks harmless. A handler that fetches a user, their settings, and their feature flags — three independent calls of 80 ms each — quietly costs 240 ms instead of 80 ms, and nothing in the code marks it as a performance decision. The tell is the same as with a loop: latency that equals the sum of the parts. ## The rejection caveat, and why Promise.all is the better default Starting promises and awaiting them later has one sharp edge. Between `getB()` being called and `await pb` being reached, `pb` has no handler attached. If B rejects during that window — say it fails in 5 ms while A takes 2 seconds — the runtime sees a rejected promise that nobody is handling and reports an unhandled rejection, even though your code does eventually await it inside a `try`. ```js const [a, b] = await Promise.all([getA(), getB()]); ``` `Promise.all` avoids that entirely: it attaches its own reactions to every input promise at once, so there is no unobserved window, and the combined promise rejects into your `try`/`catch` normally. It also expresses the intent — "these are independent, run them together" — in a way a reader cannot misread. Reach for the manual start-then-await form only when you genuinely need to interleave other work between starting and consuming. ## What to check when you read code Ask, for each `await`, whether the expression to its right depends on a value produced by an earlier `await`. If it does not, that await is a sequencing decision you did not intend to make, and the calls can be hoisted above it and combined.