That’s true, it’s not as efficient as it could be, and honestly, I probably wouldn’t try to squeeze it into one line like that on the job just for readability’s sake. I’d probably do something like:

const count = (arr) => arr.reduce((acc, newVal) => {
  acc[newVal] ? acc[newVal] += 1 : acc[newVal] = 1
  return acc;
}, {})

But to say I’m promoting bad practices seems a bit harsh. The point was doing something interesting with the function, like code golf. It’s not 100% optimized code, but it is interesting to think about things in different ways. Which was the whole point of this article.

If we’re talking about raw performance, you’re right, you shouldn’t waste any time with any of the iterators, since they are each way slower than the for loop, same with using a spread vs Object.assign. But honestly, worrying about one type of loop vs another for performance is the kind of thing that you’d usually only worry about if you have to. If you are dealing with hundreds and hundreds of objects, than yea, you probably shouldn’t be using the fancy little ES5+ tools. In day to day code though, all the iterators are more fun and readable in my opinion.

We were given new tools to make our dev experience better, I don’t really feel like we should be so quick to toss them aside. You don’t need take a drag racing car down the grocery store just because it’s faster than your Camry.