Hacker News Reader

I've literally never needed to do that. What's a real world use case?

Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.

Or, like most people, they don't work with JS outside of the frontend where fetching multiple things in parallel is rarely needed.

How is this different from await a, await b, await c?

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.

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();

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.

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.

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.

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.

I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements.

It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster.

  images = Promise.all(uris.map(loadImage))

You could also do it with a loop to start the promises and another one to await them. Is it just a shorter way of expressing that?

As per my other reply to you, there is a difference, a for loop will take the sum of each call to fetch the image while Promise.all will do the requests concurrently, meaning the total time will be that of the slowest request.

As per my other reply to your other reply, when I've written code that actually does `await` in a loop, it already does all the work concurrently. There's a code sample that illustrates what I'm familiar with.

On the other hand, the language designers are not random framework authors. They know what they're doing. There must be some reason why `Promise.all` exists. I just don't know what it is.

To re-iterate, I understand the difference between serial and parallel tasks. But I have also found that it's possible to do parallel tasks with `await` in a loop. So I'm still missing something.

To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all.

As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

For non-rejecting promises, `await Promise.all(promises)` is basically performance equivalent to `for (const p of promises) await p;`. In case you think the second one does serial work, here's a codepen for you. https://codepen.io/tomtheisen/pen/QWPOmjp

The "inner workings" could be a for loop, with the exception of rejected promises. The only opportunity for quicker resolution is when one of the promises reject, at which time Promise.all() immediately rejects.

I think the allegations of "easier" are significantly overblown too.

You are right. I was mistakenly thinking that the alternative (naive approach) would be to write the promise-creating tasks within the for loop, but if they are not part of the loop, the functionality is basically equivalent to Promise.all.

  // A -- Async and parallel
  const results = await Promise.all(data.map((i) => delay(i)));

  // B -- Functionally equivalent to the above
  const promises = data.map((i) => delay(i));
  const result = [];
  for (let a of promises) {
    const r = await a;
    result.push(r);
  }

  // C -- Problematic and naive approach: much slower
  const result = [];
  for (let i of data) {
    const r = await delay(i);
    result.push(r);
  }

I don't think that's an issue with JavaScript though. It's inherent complexity in your code's handling of concurrent operations, not incidental complexity arising from the language.

Also, wrapping callback APIs or containing side effects:

  function sleep(ms) {
    return new Promise((resolve) => setTimeout(resolve, ms));
  }
  await sleep(100);

There are some use cases for the Promise class still, and it’s great to have that kind of control facility at hand when you need it.

Promise.withResolvers can fill this gap now (though it's not natively available in Node, yet):

  function sleep(ms) {
    const { promise, resolve } = Promise.withResolvers();
    return setTimeout(resolve, ms), promise;
  }