There are plenty of online benchmarks that show this. jsperf is down for me atm, so i can't provide a link.
Some of the popular JS frameworks actually re-implement an array.forEach function as an internal for-loop to mitigate this.
I am not sure of why this is the case, and I am also not sure if the situation has improved or not since I last had to deal with the performance difference.
edit: The mozilla page about this has a polyfill for the forEach method, that shows it does more than a simple for loop:
This isn't a concern unless you're tuning performance and the loop is a bottleneck. forEach can be slower (if the JS engine doesn't inline the function body), but not to the extent that you need to structure your code around it.
Yeah, I agree with that. Which is why I mentioned performance sensitive stuff like WebGL.
Personally I use the functional methods whenever I can, but the original quote I re-posted indicates that the author thinks that for-loops should always be replaced with their functional equivalents, and I was just pointing out that this is not universally a good idea yet.
Yeah, I agree - just adding a caveat to your caveat.
Personally I found the whole article very skippable. None of it is necessarily terrible advice, but everything is overstated, and said without really explaining why its advice better than the alternatives.
Replacing ifs with ternaries and switches
with cond are hardly significant or important changes.
The whole point of abstraction (functional or object-oriented) is to push that logic from control structures in code to composition structures in runtime data.
If you weren't replacing conditionals with polymorphism, you weren't doing object-oriented programming in the first place.
`const` doesn't mean immutable data. It means immutable variables, i.e. you can't reassign to `const` variables. You can mutate the data regardless (push to an array, add a new key to an object), unless the variable points to an immutable value to begin with (primitives, or actual immutable data structures such as with Immutable.js).
12 comments
[ 3.2 ms ] story [ 17.8 ms ] threadFor loops in JS are significantly faster than .forEach() or .map()
When performance matters (WebAudio, WebGL etc), you can't easily get rid of for loops just yet.
I'm not disagreeing with you, I actually don't know, and am always happy to learn useful facts for refactoring and improved performance :)
Some of the popular JS frameworks actually re-implement an array.forEach function as an internal for-loop to mitigate this.
I am not sure of why this is the case, and I am also not sure if the situation has improved or not since I last had to deal with the performance difference.
edit: The mozilla page about this has a polyfill for the forEach method, that shows it does more than a simple for loop:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Personally I use the functional methods whenever I can, but the original quote I re-posted indicates that the author thinks that for-loops should always be replaced with their functional equivalents, and I was just pointing out that this is not universally a good idea yet.
Personally I found the whole article very skippable. None of it is necessarily terrible advice, but everything is overstated, and said without really explaining why its advice better than the alternatives.
The whole point of abstraction (functional or object-oriented) is to push that logic from control structures in code to composition structures in runtime data.
If you weren't replacing conditionals with polymorphism, you weren't doing object-oriented programming in the first place.