Get in touch
Blog
Untile|Sep 21 2022
Product | Technology

Yes, you can still use Lodash

Discover why Lodash remains a powerful utility library for JavaScript developers. Learn how to leverage its wide range of functions and simplify your coding tasks. Explore the benefits of using Lodash and unlock its full potential in your projects.

Ever since ES6 came out, there have been dozens upon dozens of articles bashing Lodash. It is one of those things that seems to be picked up and parroted across the web. While many of them are well thought-out and balanced, a definitive majority tends more towards negativity. It is understandable how we reached this point; everyone was very excited about the new native methods for arrays and objects. But I think we have gone too far and I am here to make the case for Lodash.

What they claim

ES6 supplants Lodash

While it is true that ES6 introduced the most used and most common Lodash methods to vanilla JS, it certainly does not supersede it. The new vanilla methods are not an exhaustive list of Lodash functions. Where Lodash truly shines is in its highly specific, highly situational utilities.

Just as off-the-hand examples, take `groupBy`, `pickBy`, `unzip`, `partition`, or countless others. Not every project will use them, but if you find yourself in the appropriate situation, they can be a lifesaver. Many times I am facing a particular challenge where I need to apply a very specific action to some data, and I say to myself "I bet there is a Lodash function for that". And there is! Search for Lodash on Stack Overflow and you'll find some truly wacky use cases.

Methods like this will never be included in native JS (nor should they be). They are just too specific to justify their addition.

Lodash explodes your bundle size

Being a large library filled with many many utilities, another common point against Lodash is its impact on bundle size. And on a surface level it is a valid criticism. However, if you look at your `node_modules`, you are likely to find Lodash already there, with a barely noticeable bundle size change. Many dependencies use Lodash internally. This is possible because of tree shaking. You can import just what you need and your bundler will take care of the rest, like this:

1import get from 'lodash/get';

But if you don't like the idea, and none of your dependencies actually use Lodash, you don't need to add the whole library. Every single method is also packaged as an individual dependency which you can selectively add to your projects, like so:

1import get from 'lodash.get';

Just don't do this:

1import { get } from 'lodash';

What they fail to mention

Vanilla JS is not necessarily better

Even when they seem to have the same functionality, they are different tools with different purposes. Let's have a look at `map`. It takes an array and applies a callback to each item.

1const duplicate = n => 2 * n;
2let data = [1, 2, 3];

Lodash

1map(data, duplicate);
2>[2, 4, 6]

ES6

1data.map(duplicate);[2, 4, 6]

Indeed, they look very similar and achieve the same result. But what happens when your data source isn't so well behaved? You may need to map an array that comes from an external API, or the filesystem, or any other number of sources that can fail along the way. It's easy enough if it is `undefined` or `null`, just throw in the optional chaining operator. But it can be something unpredictable like an object or a number.

1data = 200;

Lodash

1map(data, duplicate);
2// [ ]

ES6

1data?.map(duplicate);
2// TypeError: data.map is not a function
3Array.isArray(data) ? data?.map(duplicate) : [];

Vanilla forces you to be extra careful and type-check your data, while Lodash is more permissive. It's a bit like "garbage in, garbage out" vs. "silently failing" — two valid philosophies with different goals — except that Lodash never fails, not even silently. Even in extreme cases, for the `map` example, you always get an array. This is very convenient when mapping data to React components, as the DOM is always valid.

Reinventing the wheel

As for the functions that don't have a native equivalent, you'll often find people suggesting multi-line snippets to replace Lodash one-liners. And if you look under the hood, these snippets are very similar to what Lodash actually does. Lodash is a shortcut and there is no point to do yourself the work that someone else has already done.

Battle-tested

Besides this, there is a difference between code you come up with yourself (or find online), and code that is developed by a dedicated team, used and tested by millions, and optimized for many years. Lodash is battle-tested and for every method it covers every imaginable use case.

Lodash is one of the most-downloaded, most-depended upon packages from npm. And it shows no signs of stopping. It reached an all time high earlier this year, with more than 50 million downloads in a single week. That means more people trusting it, but also more people using it and testing it.

It just feels right

Lodash looks very nice and clean. That much is undeniable. It flows like a natural language and it is easier to follow along and understand. Javascript is already high-level, but Lodash is one step above it. It allows you to think more abstractly and focus on what you want to do, and not on how to do it. Of course, it is not always preferable to vanilla js. The point is that sometimes it is, and it is okay to use it. There is no shame in it.

In conclusion

Lodash is fast, modular, and fully-featured. It is not essential like it once was, but there is definitely still a place for it nowadays, and for the foreseeable future.

Other articles

Let's talk

Let's grab a (virtual) cup of coffee.

It's on us. Schedule your free consultation and let's talk about how we can help you.

Tell us something about what you expect to solve

No matter the challenge,
Untile rises to it.

No matter the problem,
Untile has the solution.

We transform businesses. We transform processes. We transform ideas.

We are Untile:
digitally, simplifying life.

Get in touch
Scroll down