Why is Lodash Still Useful?

John Au-Yeung on March 26, 2020

Subscribe to my email list now at http://jauyeung.net/subscribe/ Follow me on Twitter at https://twitter.com/AuMayeung Many more articles at http... [Read Full]
markdown guide

To do the same with ES methods, just the first two examples:


// import * as _ from "lodash";
const getRandomInteger = () => Math.round(Math.random() * 100);  
// let result = _.times(5, getRandomInteger);  
const result = Array(5).fill().map(getRandomInteger);  


//import * as _ from "lodash";
let checkPositiveNumberTimeout;
const checkPositiveNumber = e => {
  checkPositiveNumberTimeout = setTimeout(() => console.log(+e.target.value > 0), 600);

const numInput = document.querySelector("input[type=number]");  
// numInput.addEventListener("input", _.debounce(checkPositiveNumber, 600));
numInput.addEventListener("input", checkPositiveNumber);

These two example illustrate well that some things are easier to achieve without lodash than others. For me, the rule of thumb is: if I use a lodash method, I use it separately (never import all of it, and if possible, use the es version that can be tree-shaked!) and make sure I reuse it throughout the code so I actually get something in return.

In a surprisingly lot of cases I have seen, the use of utilities like lodash means outsourcing the deeper understanding of a problem to a library. While that can help speed up development in the short term, it might become a convenient habit, so much that one is tempted to overcomplicate the issue at hand in order to use these utilities when it could have been far simpler solved with native methods.

That does not mean you should not use lodash, but you should be conscientious about the implications.


but you should be conscientious about the implications.


It makes me unsure if I should use lodash.clonedeep or lodash.merge... If I write it myself, I can be sure of the implications.

Also, lodash is too magical and too widely accepting in some methods, such as lodash.filter. (I saw a lot in lowdb.)


A very nice example is _.isEmpty(): in most cases, you are testing if an object has no enumerable keys. You'll rarely need to check at the same time if the length of an array or a string is zero, but lodash will (needlessly in the stated case) check the input for all available types.

This is one of the ones that we can implement ourselves without much effort.


I think the array's built-in filter method is pretty good so I never want to use the Lodash version.


The problem with all the examples is

import * as _ from "lodash";

That'll pull in the entire lib. At this point, if you're looking for a utility, it should be very selective, much like your article suggests. That means your npm install should only pull in that utility, not the whole library.


You're right. Just import the methods you need to use. That's more efficient.


Someone in another component has already shown how to implement times and debounce.Get can be achived with optional chaining, so heres how to do keyBy:

const keyBy = (arr, key) => Obhect.fromEntries(arr.map(o => [o[key], o]))

...and with types:

const keyBy = <T extends object, K extends keyof T>(arr: T[], key: K): Record<T[K] extends (string | number) ? T[K] : never, T>

(Have't tested this since I'm on mobile rigut now, but you yet the idea)


There’s no way to do this easily with plain JavaScript without writing multiple lines of code

Since its doable in 1 line your statemet kinda false


To avoid Object.fromEntries, there is .reduce.

arr.map(o => [o[key], o]).reduce((prev, [k, v]) => { ...prev, [k]: v }, {})

Actually, with map, filter, reduce -- you can do a lot.

It is impossible to say that you cannot do something in one-liner JavaScript, because minified JS is also a one liner.


I agree. I think there're things like differenceWith in Lodash that are harder to implement by ourselves and not available in the standard library.


Thanks for the post, John! I'll admit, Lodash always felt "dirty" to me, especially since so many of its methods are now part of the ECMA standard or can be implemented in a few lines of native JavaScript. But the ones you highlighted are still very useful.


It's useful if you don't want to create your own function to do the things it does.


Can’t you now using optional chaining instead of _get()

let obj = {
  person: {
    name: "Something"
const name = obj?.person?.name

I'm not sure if it's finalized yet, but hopefully, it will be soon so that we don't need Lodash for it.


Very helpful! Thanks for sharing this worthy information.

code of conduct - report abuse