Performance

[BBCMarkMcDonnell]

Hello,

Just a quick comment that @jdalton (Microsoft) has investigated the performance implications of using native over abstraction libraries and it appears native is generally slower.

I think it would be worth making note of this within your README as it's otherwise a bit misleading.

Thanks

[jdalton]

I don't think there's a need to qualify the post as most get it.
The repo name is a bit click-bait-y but the gist of this and other projects is correct.

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.

[cht8687]

@BBCMarkMcDonnell, Hi Mark, yes you are quite right about the performance. That's why I've fixed the word to remove the claim that native is faster. 7d71473 @jdalton Great to know the goodies of Lodash. : ) I've learned a lot through you guys. Cheers.

[cht8687]

@jdalton Again John, thank you for your hard work on Lodash which makes our developers' lives easier. It is invaluable treasure for our developers.

[Integralist]

Cool. Thanks for the feedback

[stevemao]

I have created You-Dont-Know-About-Lodash-Underscore which contains performance an differences between lodash/underscore and native methods.

[jdalton]

I have created You-Dont-Know-About-Lodash-Underscore which contains performance an differences between lodash/underscore and native methods.

I appreciate the sentiment but pushing static micro benchmark results isn't that great either. I'm a fan of built-ins. As the Chakra performance PM I pushed-to and succeeded-in optimizing a few of them.

For more on lodash and JS performance see my ThunderPlains talk.
That said, the utility of Lodash is considerably more than just performance ;)

[cht8687]

@stevemao Thank you for that, but the main purpose for this list is for reminding our developers that, what methods are already native supported.

@jdalton
for your statement that:

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.

Yes you are absolutely right. But, in case I want more complex methods, my personal choice is Immutable.js, I like the performance of immutable.js in some of my Redux + React projects. I am not sure about what @gaearon 's opinion about this, but personally, I find Immutable.js as a whole is more convenient for me to gain predictability through immutability than Lodash.

[jdalton]

Yes you are absolutely right. But, in case I want more complex methods, my personal choice is Immutable.js, I like the performance of immutable.js in some of my Redux + React projects.

Lodash and Immutable are a bit different. Lodash is a generic utility library, like a stdlib, with a wider range of methods catering to more scenarios. Lodash's _.memoize.Cache even supports swapping itself out with an Immutable.Map. There are only a handful of Lodash methods that mutate values and they're clearly documented. That said, Lodash does offer immutable methods with its fp build. Using require('lodash/fp') provides immutable auto-curried iteratee-first data-last flavors of Lodash methods.

It'd be great if you could follow up on #21. A disclaimer would go a long way in clearing things up.

[cht8687]

@jdalton I've included disclaimer, let me know if you'd like any more changes regarding this issue.

[jdalton]

I've included disclaimer, let me know if you'd like any more changes regarding this issue.

That's perfect! Thank you!