DEV Community

Cover image for Let's talk about Lodash

Let's talk about Lodash

Laurie on June 04, 2021

If you were a JavaScript developer during a certain era, you're likely familiar with the library Lodash. It's a utility library full of functions t...
Collapse
 
lexlohr profile image
Alex Lohr

I found that helper tools like lodash, underscore, etc. tend to lend themselves to help the developer outsource complexity instead of actually understanding the underlying issue enough to reduce the complexity to a point where you get an elegant solution. While that may not always be possible, I find that not using lodash often results in better code. But if you use it, be sure to use it whenever it makes sense.

Collapse
 
eldarshamukhamedov profile image
Eldar Shamukhamedov

I've found the opposite. Folks write custom implementations of deep merge, intersection, is plain object, etc. and miss edge cases. These helpers then end up being used all over the place, which makes it very hard to fix any issues.

For sure use native JS built-ins over Lodash, but if you're considering writing your own version of one of the more complex Lodash helpers, at least go read their source code first.

Collapse
 
lexlohr profile image
Alex Lohr

That's what I mean with unnecessary complexity. There are less problems that strictly require these functions than one would think.

Also, things like deep cloning also have issues in lodash and other tools, see github.com/atk/object-clone-propos...

So using these tools is not a silver bullet. As I said, if you use them, make it count, but try to solve the underlying issue before you grab these tools.

Collapse
 
janpauldahlke profile image
jan paul

y the deepcopy stuff is still very viable

Collapse
 
merri profile image
Vesa Piittinen • Edited

I dislike lodash, ramda etc. as JavaScript has become quite capable in expressing meaning very well. Reading code that suddenly uses utility functions makes it much slower to understand the code as you need to look up what those functions actually do. Everybody seems to like a different library and if project has not maintained discipline, well, life becomes troublesome for a maintainer.

Of course reading specs for just one function isn't a problem, but it seems like once somebody starts to think of a problem through utility functions they sure seem to make sure to use as many different utility functions as they can in one go. They have fun learning the functions, but as a reader the functions are more of a pain - and still all too often you can refactor the code to shorter native JS while not having undesired side effects (tests are nice).

Collapse
 
lexlohr profile image
Alex Lohr

That's another good point. While some of these helpers are pretty obvious in the functionality (though not in the implementation; you'll end up with a lot of unused edge case handling, take isEmpty for example), many of them require a lot of documentation and are quite difficult to read.

Collapse
 
bulletinmybeard profile image
Robin Schulz

I've been using Lodash and Underscore since their existence and have made use of them extensively! However, this changed half a year ago when I started working on a lightweight Microservice component that I build with Node.js, where every single byte counts.

Now that I got rid of Lodash/Underscore, I basically recreated the helper functions I was using; it's even more fun to use them as I now precisely know what they're doing and with what data types I'm dealing with and ultimately no longer need to be prepared for all eventualities and types.

P.S. I kind of agree with @lexlohr . Even for me and 20+ years of experience, I often didn't even try to understand how some of the helper functions work; I just used them and got instant results, eez.

I can definitely recommend using one of the two libraries when starting a new project. As soon as you know which helper functions you ultimately need, you can start replacing the library helper functions with your logic using Lodash its .mixin() feature to extend core helper functions with custom ones. In this case, you want to overwrite core functions with your logic: dustinpfister.github.io/2018/01/31.... If this is done, you can replace the Lodash helper functions with your own helper functions.

Cheers

Collapse
 
andrenbrandao profile image
André Brandão • Edited

Hi Laurie, great article! I think I might have found a typo. Shouldn't the lines that have

const obj = { a: 1, b: { c: 3, d: 4 } }
Enter fullscreen mode Exit fullscreen mode

actually be the following?

const obj = { a: { b: { c: 3, d: 4 } } }
Enter fullscreen mode Exit fullscreen mode
Collapse
 
laurieontech profile image
Laurie

Ah ya, based on how I access it later that’s correct. I made the examples too quickly.

Collapse
 
thealexkates profile image
Alex Kates

+1 for the

import map from 'lodash/map'

Great tip, Laurie!

Collapse
 
modestfake profile image
Vitalii Saienko

You can also install lodash-es and then use

import { groupBy } from 'lodash-es'
Enter fullscreen mode Exit fullscreen mode

In this case, no Babel plugins are needed, it's tree-shakable by default. And you can use regular imports.

Collapse
 
valeriavg profile image
Valeria

Speaking of elegant solutions, it's worth checking out ramda. It heavily uses carrying and thus allows to do crazy things with very little overhead (it does the ordinary too, but what's the fun?). Tree-shake friendly, side effects free and doesn't bring bad memories :-)

Collapse
 
ifarmgolems profile image
Patrik Jajcay

Lodash also has lodash/fp

Collapse
 
mbeaudru profile image
Manuel Beaudru

Great article 👍 indeed ECMA specs have greatly improved since 2015 and we don't need to go for third-party as often as before.

One additional benefit, a major one I think, of using native VS lodash is that your IDE / tooling chain will interpret the code:

Refactoring a codebase with _get(obj, 'a.b.c') when you change "b" name is going to be difficult, while a?.b?.c can be done automatically by the IDE

Collapse
 
jenc profile image
Jen Chan

Yay!!! Thanks for describing what we don't need from the library anymore. And yes, I strongly relied on deepclone and deep merge as I didn't trust my own algos.... I agree with only importing one func instead of the whole library to keep it lightweight.

Collapse
 
xiaoyutamu profile image
Xiaoyu Li

Any typescript friendly lodash alternative?

Collapse
 
laurieontech profile image
Laurie
Collapse
 
apichatsc03 profile image
Apichart Saekrung

+1 I love that Good tools

Collapse
 
kayis profile image
K

To be honest, I maybe used Lodash under 5 times in my dev career, and then just one special function.