Hard disagree. As others have said, the string concatenation example should have been reduce instead of map, but always favor immutable, functional operations over procedural ones because it is so much easier to introduce bugs in procedural operations like for loops.
Memory consumption is rarely a factor in most JavaScript apps, and garbage collectors get better every year. This is a classic example of a premature optimization. It's better to use map (and reduce!) for pretty much everything, and then go back and optimize into loops where you know there are bottlenecks, after your codebase is more mature.
You missed the point of the article I think. The whole point of the article is to say that semantically, a map() should be stored in a variable because it creates a new array. And that if you don't care about the result and just want to do side-effects in a "functional" way (here, I use the word "functional" as opposited to with an actual for-loop statement), just use forEach() instead.
Yes, sometimes reduce() will be better and you should refactor to use it, but that's not the point here.
And yes, the argument of memory consumption was a bad way to try giving a reason not to not store the result of a map().
Some comments have been hidden by the post's author - find out more
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.
Hard disagree. As others have said, the string concatenation example should have been
reduceinstead of map, but always favor immutable, functional operations over procedural ones because it is so much easier to introduce bugs in procedural operations like for loops.Memory consumption is rarely a factor in most JavaScript apps, and garbage collectors get better every year. This is a classic example of a premature optimization. It's better to use
map(andreduce!) for pretty much everything, and then go back and optimize into loops where you know there are bottlenecks, after your codebase is more mature.Totally make sense, I also used to point out this in code reviews.
So first complete the task and then refactor it accordingly.
You missed the point of the article I think. The whole point of the article is to say that semantically, a
map()should be stored in a variable because it creates a new array. And that if you don't care about the result and just want to do side-effects in a "functional" way (here, I use the word "functional" as opposited to with an actual for-loop statement), just useforEach()instead.Yes, sometimes
reduce()will be better and you should refactor to use it, but that's not the point here.And yes, the argument of memory consumption was a bad way to try giving a reason not to not store the result of a
map().