At some level you're right that map isn't an inherently parallel construct. But I still stand by what I said, map has the potential of being parallelized on a level that a traditional for-loop does not. A for-loop explicitly surfaces a mechanism to enforce ordering, a map (and forEach) do not.
In your example, the code is not guaranteed to have a consistent result. The only way it could be consistent is if V8 guaranteed in-order execution of asynchronous tasks, which it does not.
Another differentiator in my mind is state. Anyone who has worked with distributed systems, knows that shared state is incredibly expensive. A traditional for-loop inherently provides shared state, the iterator/bounds check variable i. This inherently orders the loop, while map may be implemented as ordered, it's an implementation detail. Original MapReduce wasn't ordered.
I would say the moment you slap await in there, the code is no longer asynchronous. It's blocking as any other line.
That’s not true. If I await a web request in some random function, it will still be asynchronous as long as the random function is invoked asynchronously.
Try doing two awaits in a row and check if they run concurrently. This is the definition of synchronous.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.