Sequential versus parallel waiting

Suppose three things each take one second. Written one way the whole job takes three seconds; written another way it takes one. The code differs by a couple of characters, and nothing in the syntax shouts at you about it.

The sequential shape is `const a = await first(); const b = await second();`. The second call is not made until the first answer is in hand, because `await` parked the function before the line that starts it was ever reached.

The concurrent shape is to start everything first and await afterwards: `const pending = [first(), second()]; const results = await Promise.all(pending);`. Both calls have been made by the end of the first line — calling the function is what starts the work — and only then does anything wait.

That is the whole distinction, and it hinges on one fact worth saying on its own: calling an async function starts it. Awaiting does not start anything; it only collects.

You need two kettles boiled, three minutes each. Fill the first, switch it on, stand there until it clicks, then fill the second and stand there again: six minutes. Or fill both, switch both on, and wait: three minutes.

Notice what did not change. You are still one person, and you still cannot boil water with your hands. The kettles do the waiting; you only had to be smarter about when you started them.

That is precisely JavaScript's situation. Your one thread cannot do two things at once, but the network, the disk and the timers can all be waiting at the same time. Overlapping the waiting is free. Overlapping the working is not available.

`Promise.all(iterable)` takes a collection of promises and returns one promise standing for all of them. It fulfils when every input fulfils, with an array of their values.

The ordering guarantee is the part people misremember, so learn it exactly: MDN states that the fulfilment value is an array of values in the order of the promises passed, regardless of completion order. The slowest request finishing last does not push its result to the end of the array. This is what makes destructuring like `const [user, orders] = await Promise.all([...])` safe.

Failure is fail-fast. If any input rejects, the returned promise rejects immediately with that first rejection reason — it does not wait for the rest. And now the part that surprises people: the other operations are not cancelled. JavaScript has no way to cancel a promise. They carry on and their results are discarded, so if they have side effects, those side effects still happen.

`Promise.allSettled` waits for every input to settle and never rejects. It fulfils with one object per input: `{ status: "fulfilled", value }` or `{ status: "rejected", reason }`. Reach for it when partial success is a real outcome — uploading twelve files and reporting which three failed.

`Promise.race` settles as soon as the first input settles, whichever way it went. A rejection can win the race. That makes it the tool for timeouts: race the real work against a promise that rejects after five seconds.

`Promise.any` fulfils with the first input that fulfils and ignores rejections, only failing if every input rejects — and then it rejects with an `AggregateError` holding all the reasons. Use it for "any of these mirrors will do".

The choice is a sentence you can say out loud. All of them, or nothing: `all`. All of them, and tell me who failed: `allSettled`. First one to finish, good or bad: `race`. First one that works: `any`.

One question decides the shape. If step B genuinely needs something step A produced — you cannot load a user's orders before you know the user's id — then sequential is not a mistake, it is the requirement. Running them concurrently is impossible, not merely unwise.

If B does not need A's answer, then awaiting A before starting B is pure waiting for no reason, and `Promise.all` is the fix.

Real code is usually a mixture: two things that can start together, then a third that needs both. Group each stage, and think in stages rather than in lines.

There is a third case people forget: independent work that you deliberately serialise anyway — because a rate limit says three requests per second, or because a hundred concurrent connections would fall over. `await` inside a `for...of` loop is the right tool there, and it is a considered choice rather than an accident.

Firing everything at once. `Promise.all(tenThousandIds.map(loadOne))` opens ten thousand requests at once. The server rate-limits you, the browser queues them anyway, and one failure discards the lot. Work in batches, or use a small concurrency limit.

Using `all` where `allSettled` was meant. If you want to know which uploads failed, `all` is exactly wrong: it hands you the first rejection and throws away every successful result alongside it.

Thinking `Promise.all` makes anything faster. It does not make requests faster; it stops you waiting for them one at a time. Two 100 ms CPU-bound calculations still take 200 ms, because the single thread does both.

Assuming the losers stop. After `Promise.all` rejects or `Promise.race` settles, the other promises keep going. If they write to a database or update the screen, those effects still land — sometimes after the user has navigated away.

Calling starts the work; awaiting only collects it. Await immediately for a sequential chain, or start everything and await a combinator for concurrency. `Promise.all` returns results in input order and rejects on the first failure without cancelling anything. `allSettled` reports every outcome, `race` takes the first settlement either way, `any` takes the first success. Concurrency overlaps waiting, never computing.