The principal thing that bothers me about lodash is here's how it usually goes down: one piece of it snuggles itself initially and innocuously into a project fo

The principal thing that bothers me about lodash is here's how it usually goes down: one piece of it snuggles itself initially and innocuously into a project for a good use case... only _for the entire bag of tools_ to perniciously grow into all corners. After this happens, some projects become lodash projects instead of JavaScript projects. Those who embrace it thoroughly solve problems differently than those who don't. It's easy to become allergic to the API design, which subjectively I find old-hat compared to either native implementations or Ramda. (Yes there is lodash/fp, but there's still incongruities). And given the little variances, within the same project you generally don't want to have lodash here, FP or Ramda there - there is a cognitive cost. Dash way or the lo way? I accept that not everyone finds that a problem. More substantially problematic, if you import all of lodash and you don't enforce an agreed upon subset of its API, you might end up having its broader philosophies imposed upon you. There are others, but two that really bug me: - I'd rather not have to grok _.chain when a codebase already has a more idiomatic use of chaining. - Defensive coding is its own shed of bikes, but lodash applies it liberally, returning an empty array instead of throwing an error when fed undefined. This can obscure root causes, passing problems downstream and imposing an in-the-debugger mindset. Static analysis coverage and type safety can easily fall by the wayside. (Linters exist to alarm you if you want to prefer native versions, or exclude explicitly specific parts of lodash.)