Question

So I was having a debate with a fellow engineer about looping in JavaScript. The issue was about the native for loop construct and prototype’s each() method. Now I know there are lots of docs/blogs about for and for-each, but this debate is somewhat different and I would like to hear what some of you think.

Let’s take the following loop for example

example 1

var someArray = [blah, blah, blah,...,N];
var length = someArray.length;

for(var index = 0; index < length; index++){
    var value = someFunction(someArray[index]);
    var someOtherValue = someComplicatedFunction(value, someArray[index]);
    //do something interesting...       
}

To me, this comes second nature mainly because I learnt how to code in C and it has carried me through. Now, I use the For-each in both C# and Java (bear with me, I know we are talking about JavaScript here..) but whenever i hear for loops, i think of this guy first. Now lets look at the same example written using Prototype’s each()

example 2

var someArray = [blah, blah, blah,…..,N];
someArray.each(function(object){
    var value = someFunction(object);
    var someOtherValue = someComplicatedFunction(value, object);
    //do something interesting...   
});

In this example, right off the bat, we can see that the construct has less code, however, i think each time we loop through an object, we have to create a new function to deal with the operation in question. Thus this would preform badly with collections with large number of objects. So my buddy’s argument was that example 2 is much easier to understand and is actually cleaner than example 1 due to its functional approach. My argument is that any programmer should be able to understand example 1 since it is taught in programming 101. So the easier argument doesn’t apply and example 1 performs better than example 2. Then why bother with #2. Now after reading around i found out that when the array size is small the overhead for example 2 is minuscule. However people kept on talking about the lines of code you write is less and that example 1 is error prone. I still don’t buy those reasons, so I wanted to know what you guys think…

Answer 1

You are not creating a new function on each iteration in the second example. There is only one function that keeps getting called over and over. To clarify the point of only a single function being used, consider how would you implement the each method yourselves.

Array.prototype.each = function(fn) {
    for(var i = 0; i < this.length; i++) {
        // if "this" should refer to the current object, then
        // use call or apply on the fn object
        fn(this[i]);
    }
}

// prints each value (no new function is being created anywhere)
[1, 2, 3].each(function(v) { console.log(v); });

Sure, there is the overhead of calling a function in the first place, but unless you are dealing with massive collections, this is a non-issue in modern browsers.

Personally I prefer the second approach for the simple reason that it frees me from worrying about unnecessary details that I shouldn’t be concerned about in the first place. Say if we are looping through a collection of employee objects, then index is just an implementation detail and in most cases, if not all, can be abstracted away from the programmer by constructs such as the each method in Prototype, which by the way is now a standard in JavaScript as it has been incorporated into ECMAScript 5th ed under the name forEach.

var people = [ .. ];
for(var i /* 1 */ = 0; i /* 2 */ < people.length; i++ /* 3 */) {
    people[i /* 4 */].updateRecords();
    people[i /* 5 */].increaseSalary();
}

Marked all 5 occurrences all i inline with comments. We could have so easily eliminated the index i altogether.

people.forEach(function(person) {
    person.updateRecords();
    person.increaseSalary();
});

For me the benefit is not in lesser lines of code, but removing needless details from code. This is the same reason why most programmers jumped on the iterator in Java when it was available, and later on the enhanced for loop when it came out. The argument that the same grounds don’t hold for JavaScript just doesn’t apply.