[jonathanlydall]

If each await was to a setTimeout call waiting 1000ms, awaiting all 3 would take approximately 3000ms.

If you await a Promise.all with an array of the promises, it will take approximately 1000ms.

In summary, using individual awaits runs them serially, while Promise.all runs them concurrently.

If you’re doing CPU bound work without workers, it doesn’t make much of a difference, but if you’re doing I/O bound tasks, like HTTP requests, then doing it in parallel will likely make a significant difference.

[recursive]

I get what you're saying, but that's just not how it works in my experience. I've got a repro in codepen. What am I missing?

https://codepen.io/tomtheisen/pen/QWPOmjp

    function delay(ms) {
      return new Promise(resolve => setTimeout(resolve, ms));
    }

    async function test() {
      const start = new Date;
      const promises = Array(3).fill(null).map(() => delay(1000));
      for (const p of promises) await p;
      const end = new Date;
      console.log("elapsed", end - start); // shows about 1010
    }
    
    test();

[MrJohz]

You're starting all three promises, then waiting for the first one to finish, then waiting for the next one, then waiting for the last one. But because they were all started at the same time, they'll be run in parallel.

Whereas if you started one promise, waited for it to finish, then started the next and so on, it would take the three seconds as they won't be run in parallel.

The code you've written can be seen as a "poor-man's" Promise.all, in the sense that it's doing roughly the same thing but less clearly. It also behaves slightly differently in terms of rejections: if the final promise in the Promise.all version rejects immediately, then the whole promise will fail immediately. However, in your version, if the final promise rejects, that rejection won't be evaluated by the await (and therefore thrown) until all the other tasks have completed.

For reasons of clarity and correctness, therefore, it's usually better to just use Promise.all rather than awaiting a list of already-started promises in sequence.

[recursive]

In order to use `Promise.all`, you'd still have to construct all the promises without awaiting them. That seems like the whole foot-gun and cognitive load right there.

But the early rejection is a concrete improvement over the "poor-man's" version. I'm sold.

[jonathanlydall]

What I imagined from your initial description is that you were doing the following:

  for (var i = 0; i < 3; i++) {
    await delay(1000);
  }

However (as you are possibly well aware), this line in your example is starting all the work immediately and essentially in parallel:

  const promises = Array(3).fill(null).map(() => delay(1000));

So the timing of your for...of loop is that the first element probably takes about 1000ms to complete, and then the other two seem to happen instantly.

Promise.all is just an alternative to writing the for...of await loop:

  await Promise.all(promises); 

I guess it relies on you already being familiar with the Promise API, but I feel that Promise.all() has slightly less cognitive load to read and its intent is more immediately clear.

A strong case for preferring the Promise.all() is that Promise.allSettled(), Promise.any() and Promise.race() also exist for working with collections of promises, and unlike Promise.all(), they would not be so easily reproduced with a one liner for...of loop, so its not unreasonable to expect that JS developers should be aware of Promise.all(), meaning there is no reason for it not to be the preferred syntax for the reasons I stated above.

[recursive]

Ok, I'm a believer. I misled myself into thinking there was more going on with Promise.all than there really was. I'm mildly averse to allocating unnecessary arrays. But this is mostly superstition rather than measurable performance concern.

Promise.allSettled has a poor-mans implementation too. But the others really don't have such a thing.

My impression is that Promise.all() is kind of nice, but it's really not that big a deal or important. If it didn't exist, you could get the same happy-path code behavior without really even changing the size of the calling code.

But there's nothing wrong with it really. On balance, it seems slightly nicer than the poor-man's re-implementation. In the last 5 years, I might have been able to use it maybe twice.