Stop writing For loops. Start using underscore. | Hacker News Reader

Stop writing For loops. Start using underscore.

joelhooks.com

6 pointsjoelhooks13 comments

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) 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);

hey, good catch, I like it :>

Stop using underscore. Start using lodash.

http://lodash.com/

Faster and more complete.

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.

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`.

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 = ...")

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.

The library is a few K, which is nothing, and it's not "just for that", it's a veritable utility belt with lots of other utilities.

Agreed. Plus, underscore's implementations are not as fast as their native equivalents. At least use lodash if you're going to be using an entire library, as it is faster. Otherwise, you could just use the .reduce, .forEach, and .map constructs that are built into JavaScript (of course browser support is an issue there - but they are available for use in most modern browsers and definitely in node)

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/

It makes a lot of sense for the apps I work on. Obviously YMMV, depending on your needs and use case. JS has native implementations of several of the underscore methods, but you get into shims which is even grosser. I'll take consistency any day.

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.

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.

Reply on news.ycombinator.com