

Stop writing For loops. Start using underscore. - joelhooks
http://www.joelhooks.com/blog/2014/02/06/stop-writing-for-loops-start-using-underscorejs/

======
paulmcpazzi
I don't like using underscore or lodash for methods that are parts of the
EcmaScript specifications. I prefer using native methods (i.e. `forEach`,
`map`, etc..) and including a JS shim (like [https://github.com/es-
shims/es5-shim](https://github.com/es-shims/es5-shim)) to monkey-patch legacy
browsers.

And I know that these are just examples, but what is the point of writing:

    
    
      _.each(someArray, function(someThing) {
        doSomeWorkOn(someThing);
      })
    

when you can simply write:

    
    
      _.each(someArray, doSomeWorkOn);

~~~
joelhooks
hey, good catch, I like it :>

------
coldtea
Stop using underscore. Start using lodash.

[http://lodash.com/](http://lodash.com/)

Faster and more complete.

------
jdd
To those saying "Why bother when there is ES5?", don't forget Lo-
Dash/Underscore are more than the handful of ES5 methods. They each contain
well over 100 utility methods for everything from iterating arrays and
objects, to templates, and even function composition.

A lib can offer leeway and enhancements over bare metal language APIs. For
example, in Lo-Dash you can do callback shorthands like
`_.every(buttons,'disabled')` instead of
`buttons.every(function(button){return button.disabled});`.

Lo-Dash's methods are more consistent than shims and in many cases faster than
their ES5 counterparts. Shims have to follow the language specification which
means they have a lot more overhead than their Lo-Dash equivalents making them
slower in older environments where performance is already an issue. Shims also
fail to address engine issues like how IE<9 treats arrays like `[1, undefined,
3]` as sparse when no other engine does. Lo-Dash smooths over these issues by
treating all arrays as dense and gets better performance in the process.

Utility libs, like Lo-Dash, can give you more consistency, generally better
performance, and more features than their ES5 counterparts.

~~~
mathias
Another example is:

    
    
        _.forEach(array, function(item) {
          doSomething();
          if (condition) {
            // exits iteration early
            return false;
          }
        });
    

This is just not possible with native `Array#forEach` – you’d have to use a
plain `for` loop with a conditional `break` statement instead, or rewrite your
code to use `Array#some`.

------
masswerk
Array.forEach() anyone? What's the deeper sense in superseding built-in
features by libraries?

(I know there's IE, but ... what about just fixing Array.prototype.forEach for
those? "if (!Array.prototype.forEach) Array.prototype.forEach = ...")

------
terabytest
This doesn't make much sense. I think this would only make sense if each and
map were actual language constructs, like for example in Ruby, but in this
case you're bringing in an entire library just for that and that's a bit gross
and pointless.

~~~
spikels
But they are in Javascript! Both map and forEach were added in 2009 as part of
ES5. Problem is they weren't supported in IE until IE9.

[http://kangax.github.io/es5-compat-
table/](http://kangax.github.io/es5-compat-table/)

------
fsk
I did a test at work. For a simple loop body, a for loop is much faster than
.each. The reason is that function call is an expensive operation in
Javascript.

~~~
joelhooks
If you're writing games or rich animated consumer facing solutions, by all
mean scratch out that marginal perf boost.

In reality, it hasn't been an issue. Trivial to profile and optimize _where
required /needed_ vs standardizing on verbose, up front, YAGNI performance
gains.

Lodash benchmarks must faster than underscore in a lot of areas, and addresses
at least some of the perf issues while keeping the tasty sugar.

