What alternatives are there?

Since JavaScript loves us so much and wants us to be happy and filled with options, there are two (or three, depending on how you look at them) different ways for us to repeat the same piece of logic multiple times (other than the one you hate, of course).

Note from Author: Do note that I had to re-write the above paragraph multiple times, since I wanted the language to be as generic as possible. We’ll see why in a minute.

That said, when we think about ways to write a FOR loop that don’t involve the version we all love to hate, we come up with answers like the following.

The .forEach method of arrays

Yes, this is likely the most popular version because as JS developers we all love functional programming. Right?

We like to think of ourselves as lords of code and look down upon other loops in disgust when we use the .forEach method.

In case you’re not super familiar with it (in which case: how dare you!), this method allows you to call a function for every element inside an array. Said function will receive each element as its first argument, and your logic can use it for whatever you need.

Something like this:

Now, this is a perfectly good way of dealing with elements inside an array. However, this method — and all array methods to be honest — has one major “issue” if your logic is asynchronous: it can’t deal with it.

Let’s take another look at the above example, but let’s pretend we’re using an external service for the printing out into the console:

The result of that execution is the following:

Notice how the last line printed in the code, is actually the first one to be written into the console. We’re not getting the behavior we wanted, and that is simply because the forEach method will not await for its internal function to be finished on every iteration. And since this is a closed method, we can’t really change the way it works without re-writing it completely.

Yes, there are alternatives that deal with lists of promises, but we’re talking about FOR loops here, so let’s move on.

Another teensy tiny detail about this method is that it’s an Array method, meaning that we can’t really use it to iterate over the properties of an object for example. Not unless we first get the list of properties, like with Object.getOwnPropertyNames or similar, but that would be cheating. So let’s see what we can do about this as well.

The for..on and for..in loops

OK, so these two are very similar and can be considered as living somewhere in between the one we all hate and the forEach loop. Why? Because they provide a lower level abstraction than their functional counterpart, but not as low level as the one-who-shall-not-be-named.

Let’s take a look at both of them:

Can you spot the difference between them? It’s easy actually, the for..in iterates over the indexes of the array, and that is what it’ll assign to our local variable i . On the other hand, the for..of variation deals with the actual values inside the array.

So when picking which one, you have to remember what exactly you want to work with. If you need the indexes, use the first one, if on the other hand, you need the values directly use the second one.

“But Fernando”, I hear you say, “are they async-compatible?”. Good question dear for-loop-hater, good question. Let’s see:

As you can see, I’m using the same logic as before. What do you think the result would be here?

YES! We get the expected behavior now. And that should not come as a surprise, after all we’re dealing with a very basic construct here that allows us to define exactly what happens between iterations. So the await key works as one would expect (there is no hidden “magic” working around it as before).

Let’s also quickly test what would happen if we tried to use these loops with objects instead of arrays:

OMG, they also work with objects!! That means these already are more powerful and versatile than the .forEach method. That is wonderful. We got everything we were asking for, so why would we keep going from here?

Well, there are two main “issues” I haven’t highlighted yet with these 2 solutions:

1. We’re always iterating over the entire array/object. We can’t really loop through the last 10 elements for example. Not unless we make a copy of the original array with fewer values, that is.
2. We’ve always been dealing with arrays (or objects in the last example). But what if we have a piece of logic that needs to be executed multiple times, but does not depend on a list of elements? Do we still have to create a fake list just so we can use a loop? That doesn’t seem right, does it?

As I mentioned before, when I defined the FOR loop, the language had to be generic for this exact reason. I didn’t want to spoil the whole point of the low-level FOR loop: the flexibility to do whatever you want, however you want it.

Let’s take a look at it.