Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Gotta disagree here. In my experience, especially over the last several years, array methods have been pushed super hard in the JS community. I rarely see a simple for loop (of any flavor) these days; it's always long chains of .map().filter().map().reduce().flatMap()... Simple for loops are often criticized with a "why didn't you just use Array.{whatever}?".
Not that this is bad on the whole, I often find this much easier to read than a bunch of for loops. But that's the point that Jake makes in the video referenced in this article, and I find his examples pretty convincing: among all the array methods, reduce is by far the least readable, and it often requires time and mental gymnastics to figure out what a reduce function is doing, where a simple for loop would have been trivial to follow.
Gotta disagree here. In my experience, especially over the last several years, array methods have been pushed super hard in the JS community.
Sure the amount of content about map, filter and reduce has increased over the years but that is something you learn later down the road. I would imagine that for and while loops are still the prefered way to teach beginners about iteration.
I rarely see a simple for loop (of any flavor) these days; it's always long chains of .map().filter().map().reduce().flatMap()...
To be fair map is actually quite useful.
that's the point that Jake makes in the video referenced in this article, and I find his examples pretty convincing: among all the array methods, reduce is by far the least readable, and it often requires time and mental gymnastics to figure out what a reduce function is doing,
I like that they show cases where reduce is completely unnecesary, but that doesn't make reduce bad it's just easier to misuse. In some cases the thing that hurt readability is the inline callback with clever code trying to do everything in one expression.
Maybe I'm a gymnast, but reduce functions don't really seem all that hard to grok since they always do the same thing mechanically:
reduce((seed, next) => {
// evaluate next
// update seed or data type of seed
// return seed or data type of seed
});
Given that, any readability argument comes down to familiarity. If you've never seen a for loop (some languages lack them, ex: Haskell), you may wonder what arcane nonsense for(initializer, evaluator, incrementor){ //operation } is and why the initializer value is available in the context of the operation since the primary tool in your belt is recursion.
I would argue that the worst thing to do is mix and match. What becomes unintuitive is jumping in and out of imperative and FP concepts and having to deal with the jarring discontinuity in paradigm.
Now if I had to pick and argument for not using JS array methods at all, it would be they're not lazy and memory abusive. But that's a completely different subject.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Gotta disagree here. In my experience, especially over the last several years, array methods have been pushed super hard in the JS community. I rarely see a simple
forloop (of any flavor) these days; it's always long chains of.map().filter().map().reduce().flatMap()... Simpleforloops are often criticized with a "why didn't you just use Array.{whatever}?".Not that this is bad on the whole, I often find this much easier to read than a bunch of
forloops. But that's the point that Jake makes in the video referenced in this article, and I find his examples pretty convincing: among all the array methods,reduceis by far the least readable, and it often requires time and mental gymnastics to figure out what areducefunction is doing, where a simpleforloop would have been trivial to follow.Sure the amount of content about
map,filterandreducehas increased over the years but that is something you learn later down the road. I would imagine thatforandwhileloops are still the prefered way to teach beginners about iteration.To be fair
mapis actually quite useful.I like that they show cases where
reduceis completely unnecesary, but that doesn't makereducebad it's just easier to misuse. In some cases the thing that hurt readability is the inline callback with clever code trying to do everything in one expression.Late to the party, but I wanted to chime in.
Maybe I'm a gymnast, but reduce functions don't really seem all that hard to grok since they always do the same thing mechanically:
reduce((seed, next) => {
// evaluate next
// update seed or data type of seed
// return seed or data type of seed
});
Given that, any readability argument comes down to familiarity. If you've never seen a for loop (some languages lack them, ex: Haskell), you may wonder what arcane nonsense for(initializer, evaluator, incrementor){ //operation } is and why the initializer value is available in the context of the operation since the primary tool in your belt is recursion.
I would argue that the worst thing to do is mix and match. What becomes unintuitive is jumping in and out of imperative and FP concepts and having to deal with the jarring discontinuity in paradigm.
Now if I had to pick and argument for not using JS array methods at all, it would be they're not lazy and memory abusive. But that's a completely different subject.