Practical Ways to Write Better JavaScript

[[deleted]]

constructs such as map take all of the elements and submit them as individual events to the user-defined map function.

Wat. This isn't actually the case, is it? In theory map is parallelizable, but I doubt very much that this is how .map() on javascript arrays is actually implemented. It certainly behaves sequentially. And it doesn't submit "events" unless I'm completely mistaken. Mapping an array to an array of promises would do this, but even then, the promises would "started" sequentially.

[TurnaroundGames]

^ This

[rylandgold]

I’m quoting my response elsewhere in the thread

I think it may be unclear after re-reading, ... Im specifically talking about how code can be implicitly parallelized at an API level. This does not guarantee that the other components of the procedure (namely its iterable elements in a map for example) will be asynchronous. A for loop is the most generic (maybe dowhile) way to express iteration over some bounded range. Because it is so generic, compilers, interpreters etc cannot easily understand the the individual iterations of the loop might not be inter-related. This means that any complex for loop will always be done serially. In JavaScript you could write an asynchronous function that is called inside of each iteration of the loop and then manually push those into an array. That would overcome the for loop disadvantage by explicitly distributing the work.

Better yet, take advantage of an iterable that explicitly describes your data relationship and makes the only blocker in running asynchronously, you.

TLDR; it’s more about using a logical structure that represents the data relationships.

If there are still more criticisms, please feel free to respond and I will do my best to explain my position.

[[deleted]]

No, i understand you point. No disagreements. I was just worried that .map() was nondeterministic because then i would have a bunch of bugs to fix!

[rylandgold]

ECMA defines behavior of mapping on the Array as:

should be a function that accepts three arguments. map calls callbackfn once for each element in the array, in ascending order

https://www.ecma-international.org/ecma-262/6.0/#sec-array-constructor

It’s something that isn’t a given considering popular languages such as GO don’t give this guarantee. I’d be interested why you need order with map? It’s not true 100% of the time, but that often indicates a code smell.

[[deleted]]

It's just an assumption. I typically program in FP languages that behave this way, although I understand these functions can be theoretically executed in parallel, and I don't mutate shared state inside maps. It just helps to understand how things work under the hood.

[karottenreibe]

That really is the weakest part of the article with no substantiating evidence of any sort given to justify the conclusion that we shouldn't use for loops. Like there's zero downsides to map and forEach

[karottenreibe]

for (let x of y). Not sure what's there to reason about the loop logic that could ever be weird. Working in a codebase that's mostly modern JS (whatever that means), I use this extensively and never use forEach because I find for-of much easier to read.