You don't (may not) know Lodash/Underscore

In response to You-Dont-Need-Lodash-Underscore made by @cht8687, yes some of the methods could be replaced by native methods. This is not the case when things get a bit more complex. According to the Lodash author, @jdalton:

If you're only using a handful of methods on arrays and don't care about nullish guards, object iteration, smoothing over enviro/ES5/ES6 issues, FP goodies, iteratee shorthands, lazy evaluation, or other enhancements then built-ins are the way to go. Folks who use lodash know its 270+ modules work great combo'ed with ES6, enabling cleaner code and empowering beyond built-ins.

ESLint?

There is a plugin

Quick links

1. _.each
2. _.map
3. _.every
4. _.some
5. _.reduce
6. _.reduceRight
7. _.filter
8. _.find
9. _.findIndex
10. _.indexOf
11. _.lastIndexOf
12. _.isNaN

Note: The unit in performance field is Ops/sec.

_.each

Underscore/Lodash may exit iteration early by explicitly returning false.

// Underscore/Lodash
_.each([1, 2, 3], function(value, index) {
  console.log(value);
  return false;
});
// output: 1

// Native
[1, 2, 3].forEach(function(value, index) {
  console.log(value);
  return false; // does not exit the iteration!
});
// output: 1 2 3

Performance

⬆ back to top

_.map

Native doesn't support the _.property iteratee shorthand.

// Underscore/Lodash
var users = [
  { 'user': 'barney' },
  { 'user': 'fred' }
];
var arr = _.map(users, 'user');
console.log(arr);
// output: ['barney', 'fred']

// Native
var users = [
  { 'user': 'barney' },
  { 'user': 'fred' }
];
var arr = users.map('user');
// error!

Performance

⬆ back to top

_.every

Native doesn't support the _.property iteratee shorthand.

Performance

⬆ back to top

_.some

Native doesn't support the _.matches iteratee shorthand.

// Underscore/Lodash
var users = [
  { 'user': 'barney', 'active': true },
  { 'user': 'fred',   'active': false }
];

// using the `_.matches` iteratee shorthand
_.some(users, { 'user': 'barney', 'active': false });
// output: false

// Native
var users = [
  { 'user': 'barney', 'active': true },
  { 'user': 'fred',   'active': false }
];
var result = array.some({ 'user': 'barney', 'active': false }); // error!

Performance

Todo

⬆ back to top

_.reduce

Performance

⬆ back to top

_.reduceRight

Todo

⬆ back to top

_.filter

Native doesn't support the _.matches iteratee shorthand.

var users = [
  { 'user': 'barney', 'age': 36, 'active': true },
  { 'user': 'fred',   'age': 40, 'active': false }
];
// using the `_.matches` iteratee shorthand
_.filter(users, { 'age': 36, 'active': true });
// output: objects for ['barney']

// Native
var users = [
  { 'user': 'barney', 'age': 36, 'active': true },
  { 'user': 'fred',   'age': 40, 'active': false }
];
var filtered = users.filter({ 'age': 36, 'active': true }); // error!

Performance

Todo

⬆ back to top

_.find

Performance

Todo

⬆ back to top

_.findIndex

Performance

Todo

⬆ back to top

_.indexOf

Performance

Todo

⬆ back to top

_.lastIndexOf

Performance

Todo

⬆ back to top

_.isNaN

Native coerces the argument to a Number.

// Underscore/Lodash
console.log(_.isNaN("blabla"));
// output: false

// Native
// Confusing special-case behavior
console.log(isNaN("blabla"));
// output: true
// surprise!

// ES6
console.log(Number.isNaN("blabla"));
// output: false
// but browser support maybe the problem

⬆ back to top

References

• Mozilla Developer Network
• Underscore.js
• Lodash.js
• jsPerf

Further reading

I'd like to quote jQuery's browser bug workarounds here:

While the sentiment of youmightnotneedjquery is great, developers should be aware that ditching libraries, like jQuery, can easily require large amounts of research on their end to avoid bugs (even in modern browsers). The snippets provided by youmightnotneedjquery are a starting point but hardly scratch the surface of being a solid robust replacement to jQuery.

The great thing about an established library, like jQuery, is it’s hammered on by lots of talented people, transparently improved, and refined by the community.

Concerned over file size? When it comes to page load time, count of HTTP requests (and placement) matter far more than total JS size. And heck, jQuery 1.9.x and 2.x allow custom builds, so you can minimize what of jQuery you end up shipping.

This line from youmightnotneedjquery is worth repeating… “At the very least, make sure you know what jQuery is doing for you, and what it's not.”

~ John-David Dalton, Paul Irish

Feb 6, 2014

To extend, you should also know what your library/framework is doing. Browser support/fixing bugs is one thing. Tons of features/performance improvements should also take into account.

License

MIT