I Use For Loops Almost Always In Javascript

This topic has been worked so many times. I don't know what Kent did. Maybe he itereated over the array first to filter and then did iteration for reduce and in terms of for loo only one iteration was done. Don't know. But the truth is that in case of loop you should almost always use filter/map/reduce. First of all it's always better to have a declarative code. It produces less confusion, which as Kyle Simpson says - is a reason of most bugs. I'm not talking about one-liners vs couple line of code. Experienced programmer should know that it's not the amount of code that counts. First of all obviously the name of this array methods makes you closer to quick understand what youre about to see. You look at the code and it's a matter of second when you notice: OK, so we have some mapped data, filtered one, reduced to one value etc, whereas with for loops you know absolutely nothing about those iterations until you work them through line by line. You can't really know the outcome, purpose, anything. Secondly it requires some of the good practises of programming when using map/filter/reduce. It's rare to see some bloated code within this methods. If one sees that during code review than it's clear that someone made it wrong. In for loops there are so many place where you can make sth wrong, where somebody may overlook what you wanted to do. There is no really required structure, it probably won't be pure. When it comes to breaking the loops, you can also do that without for. Just simply use Array.prototype.every. It will do pretty much same thing.

I'd definitely agree with you for Reduce, I find the way that works and is structured to just be inherently confusing.

Map and Filter though I will usually default to, rather than a for loop. For me it's all about reducing intellectual overhead and ensuring my hands can keep up with my brain so that I don't break my flow.

So, I've noticed this pattern in my code a lot:

const ary = await Promise.all(...);
for (let elem of ary) {
    ...
}

Knowing that for ... of loops are not as fast, I started using the following construct:

const ary = await Promise.all(...);
while (ary.length) {
    let elem = ary.shift();
    ...
}

This post got me wondering how my loop compares, so I tested my way and other loop constructs here. It's interesting how much slower these other loop constructs are. Needless to say, I'm going back to the traditional for loop now!

Here are my simple test results:

Testing vanilla:      4.1ms
Testing lodash:      25.4ms -- 518% slower
Testing es6-for-of:   7.3ms --  78% slower
Testing forEach:      6.1ms --  48% slower
Testing map:          9.2ms -- 125% slower
Testing reverse:      3.4ms --  17% faster
Testing shift:       20.9ms -- 408% slower

That last paragraph really hits the nail on the head. Javascript was designed so that there are many ways to write things, so obviously the best way to write something is how you prefer it.

These people who care more about everyone doing what they are doing than actually writing good code are toxic.

I rarely use reduce because I never remember how to use it lol. The reason why I would use filter or map over a normal loop is for readability. If I see a filter I can already guess what I was trying to do in that part of the code rather than seeing a for loop and guessing. That being said I'm not working on large data so performance is never really a big concern.

At one point I was somewhat well known in the Haskell community, so functional programming feels very natural to me. And I only use for loops in JavaScript, since I have found the error messages and debugging support for map/filter/fold to be too unpleasant to use.

Nothing wrong with loops indeed. However I find filter, reduce and map useful as they are immutable and can be chained. How do you deal with these use cases?

Really good stuff. This is similar to what I heard Kyle Simpson say he is so intentional about what variable declaration he uses and where. It was cool he said that when he is using a variable that will be scoped and used though out a function he would use var to declare the variable but when creating a for loop and declaring a variable inside of it or to declare his iterator he would use let. He explained the more in the code he sticks to this thought process hopefully the easier it is to read. It really inspired me to not just ever say one thing fits all like always use === or filter or reduce they all have their place let's just be intentional.

I usually opt for a loop due to simplicity and readability, not necessarily performance. I found the premature optimization comment that you received pretty shallow because of that. With something like .reduce(...), there is mental overhead to parse it and figure out what is going on. If it isn't calculating some type of sum or total, then it is being used only for the loop aspect. In that case, just use a loop!

It seems like many JavaScript devs look at a collection that they want to loop over and say "hmmm how can I use a SICK reduce on this". It is clever and shorter, but is it more readable? Most of the time, I would disagree.

JavaScript is a language that has some functional features incorporated into it, which is great. But I think taking that to the extreme and trying to make everything functional is not always the best approach. I'm not sure why the functional stance has become so prevalent in the JavaScript community.

For loops can be clean. In ES6 we got for..of loops, they are declarative and work with more data types than just arrays.

for (let variable of iterable) {
  // statement
}

My only problem with for loops is that it takes discipline to extend their behavior in a "clean way." It is just so easy to go and add little if statement here and there (specially if you are under pressure) and before you know it you have block of code that is dificult to deal with.

Thank you for this article. I've used a lot of for loop, and recently i feel like using for loop makes me something like an "outdated" js coder. But yeah thanks, now when I use for loop I have the mindset that it gives better performance, and the future of js frameworks is all about performance.