About JSLint, its dislike of for loops, and tail call optimization

Question

I noticed that the new version of JSLint doesn't like some forms of for loops. I found that to be strange, and started digging for some explanation. Under JsLint's help page, you can find this:

The most important new feature of ES6 is proper tail calls. This has no new syntax, so jsLint doesn't see it. But it makes recursion much more attractive, which makes loops, particularly for loops, much less attractive.

And this:

jsLint does not recommend use of the for statement. Use array methods like forEach instead. The for option will suppress some warnings. The forms of for that jsLint accepts are restricted, excluding the new ES6 forms.

Both of these statements left me a byte confused. I was always under the impression that for loops were the best way of looping, mainly because:

1. Some iteration methods are not very well supported yet
2. for loops have less 'overheard' than other iteration methods

I also read somewhere that methods like forEach can't be optimized as well as a for loop, although I'm not sure if I should believe that. (Probably true in ECMAScript 5?)

So, an argument in favor of other iteration methods is that they are more readable, but, with tail call optimization coming into play, can they be as fast or probably faster than a for loop?

I'm assuming here that, for instance, forEach can be tail-call optimized, is this correct?

So, the main question is: How exactly does tail call optimization come into play when deciding in favor of iteration methods other than the for loop, in ECMAScript 6?

And perhaps also this: Is it right to assume that JSLInt likes other iteration methods better because they are more readable, and because, with the optimizations in ECMAScript 6, they can be just as fast as for loops? Did I interpret the statement's over at the JSLint help page correctly?

I'm aware that questions are supposed to have only one main question in them, and that I have many in there; but, I see them all as very related to each other, and so I think that answering one of them probably answers all of them.

Thanks, and sorry for the lengthy post!

Answer 1

I also read somewhere that methods like forEach can't be optimized as well as a for loop, although I'm not sure if I should believe that. (Probably true in ECMAScript 5?)

forEach is hard to optimise because you've got the overhead of two function calls, the callback is passed three arguments (whether or not you use them) and additionally if you use map or filter (but not forEach) you've also got the overhead of creating a new Array, rather than doing things in place.

So, an argument in favor of other iteration methods is that they are more readable, but, with tail call optimization coming into play, can they be as fast or probably faster than a for loop?

The main argument for filter and map and the like is that they create new Arrays and thus encourage immutability. Plus, they can be chained and it looks nice and readable. If performance really becomes an issue you might use a while loop or a for loop, but don't optimise prematurely.

As I'll explain below, tail call optimisation doesn't come into play with the iteration methods (forEach, map, etc.).

I'm assuming here that, for instance, forEach can be tail-call optimized, is this correct?

forEach isn't tail call optimised (as far as I know, depends as to how the browser implements it). Tail call optimisation only kicks in if a function returns the result of calling another function (that is a tail call), for example:

function factorial(n){
   if(n < 2){
     return 1;
   } else {
     return n * factorial(n - 1);
   }
 }

If you ran the above code in a browser that didn't support tail calls, you'll get an error (RangeError: Maximum call stack size exceeded for me in Chrome) if you give it a big number (e.g. 10000), because too many functions will have been called at once. Tail call recursion means that the JavaScript engine sees that you're recursively calling the same function, and will optimise accordingly and prevent itself from exceeding the maximum call stack size.

Unless your callback within forEach is using recursion, tail call optimisation won't help forEach. Because JavaScript previously lacked tail call optimisation, the previous factorial function would have been written with a while loop instead. Tail calls are now preferred for these recursive functions rather than loops.

So, the main question is: How exactly does tail call optimization come into play when deciding in favor of iteration methods other than the for loop, in ECMAScript 6?

As I said above, lots of people have been using loops rather than recursive functions so that they don't run into call stack size errors. Now, with tail call optimisation in ES6, these recursive functions become much safer to use and shouldn't throw call stack size errors. In these cases, it's now prefered to use recursion rather than loops.

And perhaps also this: Is it right to assume that JSLInt likes other iteration methods better because they are more readable, and because, with the optimizations in ECMAScript 6, they can be just as fast as for loops? Did I interpret the statement's over at the JSLint help page correctly?

Readability is a big reason for functions using recursion rather than loops (makes them easier to follow) and for using the iteration methods where possible (map to transform an array values-by-value, rather than a for loop).

If performance becomes an issue, then you'd probably want to use for loops or while loops, but there are lots of things that JSLint doesn't like that might be faster.