You don't need Lodash. Enough! Please
Hi all. Today I returned from a vacation trip, woke up, made myself some coffee, ordered breakfast, and decided to look at the finally released State Of JS 2023.
I'm reading, I open the library section – and the first thing I see is
33% of the moment is also terrifying (I’m not talking about jquery) – but let’s talk about lodash.
In recent years I have been his ardent antagonist. I believe that many people either use it incorrectly or use it without meaning – and for beginners it can even be harmful. I'll try to explain my position – let's go!
1. Installation
The first thing Lodash greets us with is a set of libraries. You have a choice:
Install the main Lodash in its entirety (but it can work crookedly on last webpack and especially Vite – and swear on ESM)
Install packages separately – but they are not updated and will then be deprecated
Install lodash-es, but it Same may work crookedly on different versions of webpack or environments (SSR/CSR), sometimes you will have to suffer with strange errors – just different than with the regular version
lodash-fp, but he deprecated 8 years ago
lodash-amd and use the AMD loader (anyone else doing this?). And the package was not updated even more than the main one
In addition, you, ideally, need to configure the bubble plugin and webpack) There are many code options to choose from
Overall, you most likely will not be able to install and use Lodash with one install command – certainly on all projects.
In addition, these individual bundles cause problems – sometimes you want to instinctively install only what you need, but they may not have been updated for more than five years – and contain vulnerabilities. And no one reads warnings from developers, of course.
And if you can, see point 2.
2.Usage
So, what the documentation recommends to us:
If we follow this recommendation, we will connect the entire Lodash bundle. The minified bundle on CDN weighs 72 kilobytes. It seems like a little, but loading all the methods on the browser will also be a bit sad.
OK! What do we have next:
So which one should we choose?
It's probably not very easy to load a complete assembly.
The core looks good, but the documentation has no information about what it includes
Why is FP needed – no one will understand
It’s convenient to load categories of methods, but there are also a bunch of them + you need to look at the doc
What am I getting at? Imagine – you are a newbie and you came here, you need to take the deep cloning method. You look at the document and don’t understand anything. What will you do?
Right. Most likely you will load the entire lodash, at best the core. It is also possible to make errors such as downloading a separate npm package – what this could lead to was written at the end of the first section.
As a result, most projects load the entire load, although they need five methods from there. Provided you configure babel, webpack (or other bundler) correctly, you have a chance to get working tree-shaking, which is not out of the box by default. lodash-es should work fine, but that's assuming there are no problems installing it – or the developer doesn't give in to solving them.
Inconsistency of packages and connections causes the following queries in the top Google for “lodash esm”:
Cool, isn't it? But we move on!
3. You use 5 methods from it
Of course, this does not apply to all projects – mainly to old ones. But an incredibly common case is when a developer connects a lodash for the sake of… one or two functions.
In the modern stack, A LOT of Lodash methods have already been ported. I like to ask a question in interviews – how to deeply clone an object? More than half, especially beginners, call it “lodash deepclone” – which, in my opinion, is a problem, provided that there is structuredClone, which has good support and polyfills, as well as a bunch of lightweight modern libraries.
As a result, lodash in many cases allows you to do what is ALREADY supported in JS… but worse. It is clear that some methods are “indispensable”, but let's take a few examples:
And so on. But you say, what about indispensable methods? Let's look at the ones I saw most often:
debounce -> this is a few lines of code. You can write your own tiny method with a convenient API and the way you need
delay -> this is generally setTimeout, it’s better to write your own asynchronous sleep in 5 lines of code
clone -> structuredClone covers almost everything except something reactive
This is one of those methods that I cannot recommend as 100% replaceable – I would replace it with a cloning library – by type https://www.npmjs.com/package/klona
difference -> there are no normal replacements, but there are replacements like deep-object-diff and others (and there’s not a lot of code there! For example, we wrote our own method based on deep-object-diff)
Otherwise, according to my observation, other methods are either not used or can be very easily replaced by native ones.
4. modern is a lie
The lodash website states that it is modern – which is far from the truth. Lodash does not use modern builders, has not been updated for years, many methods are in the native (and the native ones will probably be faster – and at least not eat up space/memory).
In addition, when using lodash analogues instead of native, you miss the opportunity to keep track of what is added to the native – and there is a lot of very interesting stuff there! All sorts of toSorted, new collection methods – can be used in a node, you can cover yourself with polyfills (depending on what browser versions you need). Using these methods also improves your knowledge as a Javascripter. And for this pumping you definitely don’t need a lodash.
Summary
Lodash:
Has multiple installation methods, each of which can cause problems and connection headaches
Easily connects entirely instead of several methods you need
Is not updated
Not needed in 95% of cases
Prevents understanding of truly modern methods
You don't need lodash. Go through your methods, throw out those available in native, replace those that are not available (if you definitely need them).
And if you do use it:
Use the es version with crutches for TS, if necessary, or the regular one with plugins for tree-shaking
Don't use these separate packages – only
lodashorlodash-esDon't increase its usage percentage in your code. Please
Maybe you also use Moment? It's time to update too!
Good example
I would like to show the wonderful guys from UnJS who created a set of un-iversal libraries: https://unjs.io
Why is this top:
Really modern and very lightweight code with minimal assembly
Decomposed packages – take what you need
There is no need to install any babel/ts plugins – everything works out of the box as soon as you import it. Install and use!
I've been wanting to do this article for a long time. Are there any lodash fans here? Share, will you continue to use it after all the points above – and why? And if you’ve been wanting to leave for a long time, but didn’t have enough arguments, go for it 🙂
And we read State Of JS 2023: https://2023.stateofjs.com/en-US (I wrote a summary in Russian in my tg channel: https://t.me/webdanil/137. It’s possible to do this, right? It seems like I’m not doing PR… almost…)
