8 ms·

You Might Not Need Underscore

8 points by ville 11y ago

mc_hammer 11y ago
true but underscore had the features first... so, i might not need es2015. also i have no idea how to install es2015 or the browser compatibility it brings. thx for the info though. :)
- ville 11y ago
  Check out Babel (https://babeljs.io/ https://babeljs.io/). If you're already using some kind of build setup for your JavaScript, adding Babel is very easy and quite a few projects are using it already.
inglor 11y ago
`Array.from({ length: n }, (v, k) => k + x)` this is a terrible way to create a range, it only works incidentally. Please do not use it.
- peferron 11y ago
  Which part of the spec makes you think it only works incidentally? http://www.ecma-international.org/ecma-262/6.0/#sec-array.from http://www.ecma-international.org/ecma-262/6.0/#sec-array.fr...
  - inglor 11y ago
    The part where you're abusing an old "array like" and the way Array.from works with it and uses the index argument in the mapper argument to force it into a range. How many people do you think understand what `Array.from({length: 5})` works?
    - peferron 11y ago
      Your comment sounded like it only worked because of implementation details in the JS engines. That would have been a much bigger deal than just not liking the style. Out of curiosity, how would you do it yourself?
fabien_ 11y ago
Underscore : _.each(array, iteratee) ES5.1 : array.forEach(iteratee) And all the other elements... Yes, you are right. But... The "array" is not always an Array. document.getElementsByClassName( 'myClass' ) is not an Array but a DOMNodeList. So document.getElementsByClassName( 'myClass' ).forEach(iteratee) will not work. Same for map, reduce... Underscore (or lodash) makes more that just polyfilling es5 methods.
- julienng 11y ago
  Do something like: NodeList.prototype.__proto__ = Array.prototype;
- paulcpederson 11y ago
  var myClass = document.getElementsByClassName('myClass') Array.prototype.slice.call(myClass).forEach(iteratee)
togakangaroo 11y ago
Interesting post with a few neat things I didn't know (spread on an object? Very cool) But then you still have. To deal with awesome functional helpers like denounce, not to mention insanely useful things like cloneDeep and zipObject. Instead I'd note to use the natives tuff wherever possible and use lodash to pull in just the functions you need piecemeal. Oh and you should certainly mention Function.prototype.reduce and Object.assign
LocalPCGuy 11y ago
The article doesn't touch at all on the performance of lodash compared to underscore or even native functions. In many cases it is more performant. So while you do have to decide if the extra library load is balance by the better performance in your specific use case, it should be considered. Also, there is the simple fact a lot of people like the abstraction compared to the native solution - it is often simpler to use and remember.
- stymaar 11y ago
  > In many cases it is more performant Imho, choosing to use a library like lodash in the beginning of your project for performance reasons is a premature optimisation. In 90% of the projects, the speed of Array.prototype.map compared to _.map will never be part of the performance bottleneck. > it is often simpler to use and remember Maybe people are used to one library's api, and expect the native counterpart to be more difficult, but the examples given in the article are counter examples to this statement.
  - jdd 11y ago
    You use something like lodash from the start so you know out of the gate you're getting something modular, consistent, feature rich, that also happens to perform well. Using a library like lodash gives wiggle room between you and the language. This wiggle room allows for increased consistency, added features, and performance improvements. For example ES6 introduces changes in `Object.keys` to support string values. Lodash standardizes the behavior so it's consistent across es3, es5, and es6 environments.
- gotofritz 11y ago
  There is a feeling among many people that too many "js devs" only know jquery or _ or angular and not the whole breadth of the language. Articles like these are there to show that you don't need to include the whole _ if all you need is a simple "pluck" for instance. Of course there are good reasons for using those libraries, it's all about tradeoffs.
GreLI 11y ago
What about _.flatten()? E.g. to flatten an array before find()? Just thought of 1-level flattening [].concat(...array). But it not that explicit. Also, array.find(i => i.foo == 'bar') isn't as readable as _.find(array, { foo: 'bar' }).
haromaster 11y ago
There is some really good points here. However, i feel a lot of these 'You might not need...' articles are often a straw man response to the idea that developers only use libraries because they are easier to code, not because (some of them) solve cross-browser issues or provide better performance, offer features that there isn't a 1:1 native method for etc.
- oceanswave 11y ago
  Exactly this.
maroshii 11y ago
One of the advantages of underscore (and lodash) is that you can iterate over arrays AND objects indistinctly in most cases. How would you do: var a1b2 = _.reduceRight({a:1,b:2},(memo,val,key) => key+val+memo,''); or: var two = _.find({a:2,b:3,c:4},(val,key) => key !== 'a' && key !== 'c' ) Until I see _.chain, _.compose, _.partialRight, _.zip or _.throttle (among others) implemented in the standard library lodash is a no-opt. With iterables and the "for of" loop javascript is definitely not going in the direction of functional programming though.

8 points by ville 11y ago

true but underscore had the features first... so, i might not need es2015. also i have no idea how to install es2015 or the browser compatibility it brings. thx for the info though. :)

ville 11y ago
Check out Babel (https://babeljs.io/ https://babeljs.io/). If you're already using some kind of build setup for your JavaScript, adding Babel is very easy and quite a few projects are using it already.

inglor 11y ago

`Array.from({ length: n }, (v, k) => k + x)` this is a terrible way to create a range, it only works incidentally. Please do not use it.

peferron 11y ago
Which part of the spec makes you think it only works incidentally? http://www.ecma-international.org/ecma-262/6.0/#sec-array.from http://www.ecma-international.org/ecma-262/6.0/#sec-array.fr...
- inglor 11y ago
  The part where you're abusing an old "array like" and the way Array.from works with it and uses the index argument in the mapper argument to force it into a range. How many people do you think understand what `Array.from({length: 5})` works?
  - peferron 11y ago
    Your comment sounded like it only worked because of implementation details in the JS engines. That would have been a much bigger deal than just not liking the style. Out of curiosity, how would you do it yourself?

fabien_ 11y ago

Underscore : _.each(array, iteratee) ES5.1 : array.forEach(iteratee) And all the other elements... Yes, you are right. But... The "array" is not always an Array. document.getElementsByClassName( 'myClass' ) is not an Array but a DOMNodeList. So document.getElementsByClassName( 'myClass' ).forEach(iteratee) will not work. Same for map, reduce... Underscore (or lodash) makes more that just polyfilling es5 methods.

julienng 11y ago
Do something like: NodeList.prototype.__proto__ = Array.prototype;
paulcpederson 11y ago
var myClass = document.getElementsByClassName('myClass') Array.prototype.slice.call(myClass).forEach(iteratee)

togakangaroo 11y ago

Interesting post with a few neat things I didn't know (spread on an object? Very cool) But then you still have. To deal with awesome functional helpers like denounce, not to mention insanely useful things like cloneDeep and zipObject. Instead I'd note to use the natives tuff wherever possible and use lodash to pull in just the functions you need piecemeal. Oh and you should certainly mention Function.prototype.reduce and Object.assign

LocalPCGuy 11y ago

The article doesn't touch at all on the performance of lodash compared to underscore or even native functions. In many cases it is more performant. So while you do have to decide if the extra library load is balance by the better performance in your specific use case, it should be considered. Also, there is the simple fact a lot of people like the abstraction compared to the native solution - it is often simpler to use and remember.

stymaar 11y ago
> In many cases it is more performant Imho, choosing to use a library like lodash in the beginning of your project for performance reasons is a premature optimisation. In 90% of the projects, the speed of Array.prototype.map compared to _.map will never be part of the performance bottleneck. > it is often simpler to use and remember Maybe people are used to one library's api, and expect the native counterpart to be more difficult, but the examples given in the article are counter examples to this statement.
- jdd 11y ago
  You use something like lodash from the start so you know out of the gate you're getting something modular, consistent, feature rich, that also happens to perform well. Using a library like lodash gives wiggle room between you and the language. This wiggle room allows for increased consistency, added features, and performance improvements. For example ES6 introduces changes in `Object.keys` to support string values. Lodash standardizes the behavior so it's consistent across es3, es5, and es6 environments.
gotofritz 11y ago
There is a feeling among many people that too many "js devs" only know jquery or _ or angular and not the whole breadth of the language. Articles like these are there to show that you don't need to include the whole _ if all you need is a simple "pluck" for instance. Of course there are good reasons for using those libraries, it's all about tradeoffs.

GreLI 11y ago

What about _.flatten()? E.g. to flatten an array before find()? Just thought of 1-level flattening [].concat(...array). But it not that explicit. Also, array.find(i => i.foo == 'bar') isn't as readable as _.find(array, { foo: 'bar' }).

haromaster 11y ago

There is some really good points here. However, i feel a lot of these 'You might not need...' articles are often a straw man response to the idea that developers only use libraries because they are easier to code, not because (some of them) solve cross-browser issues or provide better performance, offer features that there isn't a 1:1 native method for etc.

oceanswave 11y ago
Exactly this.

maroshii 11y ago

One of the advantages of underscore (and lodash) is that you can iterate over arrays AND objects indistinctly in most cases. How would you do: var a1b2 = _.reduceRight({a:1,b:2},(memo,val,key) => key+val+memo,''); or: var two = _.find({a:2,b:3,c:4},(val,key) => key !== 'a' && key !== 'c' ) Until I see _.chain, _.compose, _.partialRight, _.zip or _.throttle (among others) implemented in the standard library lodash is a no-opt. With iterables and the "for of" loop javascript is definitely not going in the direction of functional programming though.