The point of `Promise.all` is to have every promise passed to it to start computing concurrently, likely in parallel if they e.g. start independent I/O operations.
The point of `Promise.all` is to have every promise passed to it to start computing concurrently, likely in parallel if they e.g. start independent I/O operations.
// Given:
const fooPromise = asyncFoo();
const barPromise = asyncBar();
// Then this...
await fooPromise;
await barPromise;
// ...is equivalent to this:
await Promise.all([fooPromise, barPromise]);
Now, Promise.all() is useful, but it is unrelated to when computation starts.The misunderstanding in the article has to do with misunderstanding when a promise is executed. It’s easy to wonder why calling await on a promise directly vs calling it on a variable containing a promise is different. The difference is promises execute immediately on creation while await blocks on a promise. So a promise that is created after an await will be executed after that awaited promise is resolved.
Consider:
const x = await foo();
await bar(x);
How can you schedule `foo()` and `bar()` in parallel, when they have an explicit data dependency?You can't, but that's a fundamentally different scenario than what's being discussed.
`await` should just return control to the event loop (ie. actually transform the remaining code into a callback). If you've issued the two promises before that happens both should be able to start operation.
As far as I know the difference here would be effectively (in very loose pseudo-code:
fetch(first).then {
fetch(second).then {
doThings();
};
};
vs. a = fetch(first);
b = fetch(second);
a.then { b.then { doStuff(); } };
which to my understanding should do both fetches in parallel even though the resolution is not.Looking at a bunch of articles about "how Promise.all can be implemented" it looks like this kind of recursive resolution of the promises is one of the methods that's expected to work (if not perform terribly well in the general case)?
See this SO answer for eg. as well: https://stackoverflow.com/a/46348155
I expected `await X` to create the promise `X` when it starts executing, much like `cond_A || cond_B` only computes `cond_B` when `cond_A` has been computed and turned out falsy.
Else how the following code ever work correctly?
const x = await foo();
const y = await bar(x);
We cannot schedule `bar()` before we have computed its inputs.OTOH `(await x()).concat(await y())` could speculatively compute both promises concurrently, even if it does not yet know whether the result of `x()` has a property named `concat`. I won't normally expect it, but JS is used to defy logic in many areas :-\
In the example you've shown, it is absolutely correct that the two promises must be sequentially awaited like that. The OP is talking about a situation where there is no dependency between x and y.
Personally I agree that this is cleaner than the Promise.all() solution, but I also think it emphasizes just how misleading the syntax can be, given that those weighing in on this thread can't even agree what this code will do without trying it out.