4 ms·

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

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.

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.