No need to choose, I use the ES6/ES7 versions when they exist and import the lodash functions on a case-by-case basis for the huge number of them that don't exist natively in ES6/ES7.

I almost always use lodash.

As others have pointed out it is strongly performance oriented and can be imported in a piecemeal fashion for minimal bundle sizes.

One more very practical reason is that if you know the lodash API well you can defer almost all of your null/undefined/edge-case checks to lodash.

I am very particular about unnecessary branching and superfluous code that usually litters imperative code making it difficult to reason about the behavior.

Lodash (along with a few conventions) helps me get rid of this cruft significantly.

For example: Lodash map ,forEach etc will do the null check for you and won't complain if your collection is actually null. invoke can handle invocation of functions which may be missing. get, set allow you to safely work with deeply nested objects.

FP's curried functions and data last approach takes a while to get used to but can heavily cut down on the lots of trivial functions that are omnipresent in most javascript codebases which exist "just" to compose pieces together, and have no behavior on their own.

The primary idea is to structure your code in such a way that the control flow can focus on the happy path and a reviewer/future maintainer does not have to be bogged down by edge case handling code while reading it.

Practices like newspaper pattern also significantly help in this regard.

Of course there are more sophisticated ways towards this goal, but for javascript projects, especially where you are not the instigator, lodash is, in practice, one of the least intrusive options that is either already present or can be pulled in with no objections from current team.

It is a matter of needs I believe and a very opinionated choice. I know that lodash performs better than native in some operations, but damn! Spread operator is way more elegant and safe than Object.assign, which is also offered by _.assign.

.map, .filter, .reduce, .some, .every maps iterable objects and also arrays, which in some contexts is really handy and optimal, but in other contexts is misleading.

Also, have you heard of Ramda? I would say, the three solutions adapt to different needs.

After ES6, I never looked back to underscore. I tried lodash for one project. But with ES6 I feel home, I don't want to add an extra dependency, out of all the lib there is only a very few functions are usable, so sticking to basic make me happy.

I've just found this one earlier today: github.com/you-dont-need/you-dont-need-lodash-und…

I prefer to do native JS if possible, but for some things I just use individual lodash functions direcly.

Things were very different before ES6 Javascript. Back then, I would advise everyone to get acquainted with underscore/lodash, but nowadays things are different.

There are two videos that completely changed my mind:

Sebastian Markbage's "Minimal API

Cheng Lou's Taming the MetaLanguage

Now, that's not to say that lodash should never be used. There are still some functions in the library that help a great deal to prevent writing very complex utility functions.

But for certain simple things like plucking an object property out of an array of objects or simple sorting, map and sort can handle those very handily.

It always pains me when I have to look up documentation just to see how something simple is being done. This relates to Cheng Lou's talk about how things get easier when ideas are baked into the language rather than left to hang out in the documentation of a third-party library.

If you want to use lodash, feel free to do so, but realize that there's a cost to the extra meta-language of learning yet another API when something more simple can do the job.

You shouldn't be pulling in a dependency just to make things "look better". If you save a few extra lines of code, but end up requiring another developer to do a google search, are you really making things simpler or are you just trying to please yourself?

First, let me say that I'm a big fan of Lodash and still use it in several projects, but for some time now I prefer to write my own helpers or use a custom build of Lodash.

Keeping things simple and dependency free is what I strive for lately. Writing your own helper functions is better than bloating the project with yet another dependency.

That being said, there are still times where using Lodash is the more rational decision:

• when every ms matters - Lodash is strongly performance oriented. ( _.bind is faster than Function.prototype.bind)
• your team doesn't have the time (or doesn't want) to maintain in-house utility library - for a small team, where deadlines prowl behind every corner, using Lodash is more logical.
• you don't want to rewrite the same logic every time - several projects may depend on the same functions, lets say curry and debounce . Instead of rewriting it, you can just import it.
• you don't need to support old browsers (I look at you IE) - Lodash droped support for older IEs. If you still need to support them, my sincere apologies.

Lodash is a very tinny library which goes well with Vanilla JS, especially with ES6 modules, however, I am not using it, yet, I'm fine to extract only functions I need.

If we are going to look on small component as an independent piece of app where you can achieve what Lodash function offers you with a bit more vanilla JS characters, then why not, your component doesn't has needless dependency and you can re-use it in any other code in the world without worrying about any dependencies you might need to install/use as well.

Usually I have own small helpers and BunnyJS

After all it just depends on a project, team, company.

Lodash, hands down. No project operates without dependency and I'm going to say that Lodash is a necessary dependency. I come from a heavy underscore.js background. So, I obviously love Lodash.

For starters, the readability of Lodash is beautiful compared to JavaScript's Array reduce.

The problem with native JavaScript is that, you have to write your own functions on the fly and different engineers in your team are going to do it in different ways. Not to mention, if you're writing your own functions, there's a possibility of it being error prone.

This library is developed by people, whose job is to make sure the functions they offer operate at a very optimal level. I would strongly recommend to go the lodash way rather than the native way, but hey, that's just me. I am guessing Sai Kishore Komanduri will have some views that are rather different from mine on this.