On top of this, I don’t think JavaScript has iterator fusion, so chaining maps and filters should be less efficient than using a for loop. Using jsbenchmark:

# setup
let DATA = [...Array(10000).keys()]

# 9k ops/sec
DATA.filter((x) => x % 2 == 0).map((x) => x ** 2).filter((x) => x > 1e6)

# 18k ops/sec
out = []
for (let entry of DATA) {
  if (entry % 2 == 0) {
    let x = entry ** 2;
    if (x > 1e6) {
      out.push(x)
    }
  }
}

For whatever it’s worth, this reduce is roughly 4-6x faster than the author’s flatten, as well as significantly easier to understand

list_of_lists.reduce((acc, lst) => lst.concat(acc), [])

Though it’s still way slower than the for loop

And then this reduce, which is equivalent to their for loop, is just a tiny hair slower than it!

list_of_lists.reduce((acc, lst) => { acc.push(...lst); return acc } , [])

I suspect the difference is that [...acc, ...lst] (which has to unpack two arrays to make a third) is significantly slower than acc.push(...lst); (which only has to unpack one array and append to one array).

So I don’t think “for loops are faster than reduces” is the relevant performance advice here, but “avoid allocations they’re expensive”

(Though I think probably generally the performance point does hold!)

jsbenchmark link

I generally recommend developers at work to use for-of loops in JS, rather than map, filter, reduce. Despite being mainly a functional programmer outside of work.

There’s a few things, similar to what the post mentions:

• map, filter, reduce are often used with short arrow functions. That’s easy enough to maintain when short, but over time as the function body grows, often un-named and un-typed functions end up being given as arguments to map, or reduce in particular.
• The logic is usually chained, .map().filter(), when the most optimal approach would be to do them in one iteration, rather than two.
• Often loops will want to be broken out of early, which is easiest to do via continue. I’ve seen lots of accidental performance leaks because a developer used map().filter() when they only needed to calculate one result.
• Sometimes .map() is used instead of .forEach, and I find it’s much cleaner to identify what is being done with each element if a normal for..of loop is used.

All that being said, I also do think for..of has a naming problem. for..in is too close, too easy to mistakenly use (e.g if you have been writing Python lately). There’s also the case when it comes to promises - if you have an array of promises, it’s more efficient to use .map with Promise.all rather than using for..of, which will block on each awaited element. It’s another place where I’ve seen quick performance wins.

I’ll admit, I like array methods enough to have gotten kind of obnoxious with reducers over the years. I especially preferred them when JavaScript didn’t yet have for…of. I realize now that unless you’re doing something trivial like sum, JavaScript reducers aren’t very readable for most people. Even sum can be messed up by passing an empty array and no seed value into the reducer.

With that mea culpa out of the way, I posit the following counterargument: One can spend an eternity correcting the iteration style of one’s colleagues only to find that the actual performance bottlenecks are in array destructuring (more expensive than you think and used in the examples here), un-memoized functions, over-eager effects, and, of course, dependency bloat. Then, when someone adds some function calls inside a really big for loop (either because it’s getting too big to read easily or because they have to use code from an external module), the performance difference evaporates.

There are merits to the arguments in this article, especially the readability ones. I would just caution developers not to impose an iteration style dogma on a JavaScript codebase on performance grounds. In most cases, there aren’t nearly enough iterations for this to be the performance cost you’re looking for. If you’re going to optimize anything up front, it should be holistic, like where you do which computations, when, in what runtime, and how it all is supposed to hang together.

I think everyone goes a through a phase where they try to use reduce for everything.

No matter the language. I’m not ashamed to use filter and map where it suits me and for-loops where it doesn’t.

I suppose my only code that is “pure” is in languages where either map/filter is very annoying to do (e.g. PHP), nonexistant and I don’t use for-loops if they suck (e.g. clojure)

Kotlin is especially bad here (for me) as I’m just learning it and still use a lot of for like in Java or.. by default, but most things can be neatly done with filter/map. Eh, whatever. I guess I should improve.