Lodash and usefulness of utility libraries

On this blog, we’ve already explored quite a few native JS APIs very deeply… Likes of ES6 data structures, versatile arrays or advance logging capabilities of Console API, are all features that you can use in your code right away (if your browser doesn’t lack behind the latest specs 🙃). But, there are times that native methods are just not enough. Times when we need to call in the big gun! 🔥 And so, today we’re going to explore a library that will let us do just that! Say “Hello” to Lodash!

What’s Lodash?

There are very, very high chances that you already know and probably even use Lodash. Why? Well, because it’s the most depended-upon and probably the most popular library on NPM’s registry. So, if you do know it, then consider this article a refresh or just a (hopefully) nice read. Otherwise, what is Lodash? Naturally, it’s a JS library - utility library. ⚒ This means that it provides a huge collection of different methods, often serving completely separate purposes. Some can easily prove to be useful and make your code less bloated, while others can simply be wrappers around native functionalities provided for convenience.

Leaving Lodash behind for a second, there are many other JS utility libraries out there. While Lodash is certainly the most popular and (most likely) complete option, the list includes likes of Underscore and Ramda. Underscore can, quite frankly, be considered Lodash precursor, with Lodash originally starting as a fork of Underscore. From this fact alone, you can consider Lodash to be a superior toolset.

On the other hand, we have Ramda. It represents a special kind of utility library, specifically tailored at a certain way of solving problems. In this case, Ramda is targeted towards functional programming. Here, Lodash has something to say too, as it provides a functional-programming-style-friendly version of its API.

On top of all that, Lodash also has a modular architecture. This is important, especially with around 69 KB worth of minified code. As you’ll most likely never use Lodash to its full extent. That’s why having the ability to only include what’s needed is really important - even more so when fighting giant bundle sizes! 👊

Should I use it?

Everything up to this point looks quite fine, doesn’t it? Utility library, improving the style and readability of the code, increasing productivity, combined with modular architecture and JS FP flavor support. So, with all these advantages, just why not? Brace yourself! - here comes the controversy! 😅

Just as I mentioned before, Lodash and alike beyond useful and not-natively-implemented methods, provide those that are already built into JS itself. From the observer’s point of view, it’s only an advantage, especially with the library’s modular structure. The problem begins when you start to actually use the library. The experience it provides you is so good, that you just fell into an invisible trap. 🕳 Because of a factor called convenience, you start to use a particular library to a higher and higher extent. And thus, you start using the methods that are equally easily available inside the JS itself.

And this brings us to the next thing, which is performance. Lodash is extremely well-optimized as far as modern JS goes, but, as you may know, nothing can be faster than native implementation. Even if Lodash uses the same API under-the-hood, function call overhead is still present. Some might say that these are just some micro-optimizations. But, image what would happen if you use Lodash all over your code? Then the performance hit can be a little bigger. And, with the native API having a similar form, just why not use that instead?

We could also argue that if programmers would use Lodash to a too great extent, they might forget how to work with the underlying API. It’s always good to have at least some know-how about what we’re using under-the-hood. But still, this aspect can be debatable, as the code is meant to be reused as much as possible, right? 🤔

Now, don’t get me wrong - Lodash isn’t a bad or evil tool of any kind. It’s totally the opposite - it’s useful and awesome. You just shouldn’t get into it so much. Remember that JS itself still provides a lot of methods on its own. Its Lodash features that JS doesn’t have (or sometimes needs polyfills for), that you should definitely use when needed. Examples of that are object deep clone and object difference - two of the most important Lodash functionalities for me, personally.

API overview

After all that talk of mine, you probably wonder how Lodash’s API actually look like (if you haven’t check it out before). Its API as a whole is too big to cover, but, such a thing would be pointless anyway, because of its high-quality documentation. 📖 Instead what we’re going to do, is a quick overview of categories of methods that Lodash provides, and their general usefulness when compared to native APIs.

Array

Naturally, all Lodash array methods works on… arrays. It’s probably the biggest collection of Lodash methods, and for good reason. It includes methods allowing you to easily get the difference of two arrays ([_.difference()](https://lodash.com/docs/4.17.11#difference)), ensures all values are unique ([_.uniq()](https://lodash.com/docs/4.17.11#uniq)), and remove any of them with ease ([_.remove()](https://lodash.com/docs/4.17.11#remove)). Just remember that there are some “useless” methods too. Examples of such are [_.join()](https://lodash.com/docs/4.17.11#join), [_.reverse()](https://lodash.com/docs/4.17.11#reverse), and [_.indexOf()](https://lodash.com/docs/4.17.11#indexOf) - all of which are natively built into JS in the same form! With ES6 this list becomes even longer!

Collection

Collection, in Lodash vocabulary, seems to be used to reference an object or an array (sometimes even a string). And this group includes methods that can be used to work with them. Combining the ease-of-use of array methods with objects can be especially useful. Of course, such collections even with nice API cannot be considered a data structure on its own. E.g. when iterating over an object, you cannot be sure of the order of its properties (like with arrays). If real data structures are what you want, then you might have to use a different library (e.g. Immutable.js). Otherwise, these methods truly simplify any kind of interaction with objects (arrays have most of these methods built-in).

Date

When it comes to date collection, there’s only one, “useless” method - [_.now()](https://lodash.com/docs/4.17.11#now). Just don’t bother at all and, please, use [Date.now()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now) instead. 🙃

Function

Function collection most probably includes some of the most complex methods. You might argue with me here, but the [.bind()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind) is often the only method JS developers use when it comes to Function API. But here, Lodash provides us with many helpful shorthands for some of the functions-related stuff. Examples of this include often used throttling and memoization. Of course, these methods may not be used as often as others, but definitely provides something that’s (mostly) not available in vanilla JS in such convenient form.

Lang

Lang collection is very diversified. It contains methods that work on a variety of data types. These cover various is checks (e.g. [_.isArray()](https://lodash.com/docs/4.17.11#isArray), [_.isNumber()](https://lodash.com/docs/4.17.11#isNumber)), value conversions (e.g. [_.toNumber()](https://lodash.com/docs/4.17.11#isNumber), [_.toString()](https://lodash.com/docs/4.17.11#toString)), cloning and deep cloning functionalities. While the first two categories don’t require much boilerplate when used with plain JS (recommended), the cloning methods are very useful. They provide a nice alternative for unavailable in some browsers [Object.assign()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign), and, when it comes to the deep version, they provide features that even mentioned native method doesn’t cover!

Math

While I will leave using Lodash methods like [_.add()](https://lodash.com/docs/4.17.11#add) without a comment 😅, methods from Math collection that operates on number arrays can prove to be quite useful. Of course, you can just use the native [.map()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) or [.reduce()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce) methods from built-in Array API, but, arguably, the convenience of just calling e.g. [_.max()](https://lodash.com/docs/4.17.11#max) or [_.mean()](/lodash-and-usefulness-of-utility-libraries/mean) is just too high to ignore.

Number

Number collection, in fact, includes only 3 methods i.e. [_.clamp()](https://lodash.com/docs/4.17.11#clamp), [_.inRange()](https://lodash.com/docs/4.17.11#inRange) and [_.random()](https://lodash.com/docs/4.17.11#random), all of which provide some casual functionalities with additional features. Take _.random() for example. Instead of outputting completely random number (like usual), you can easily limit it to a certain range and decide whether you want it to be an integer or floating-point number with just a simple set of arguments. It is for such details that many developers have fallen in love with Lodash. 💕

Object

Object collection, just like the array one, groups methods that work primarily on objects. What about their usefulness? Well, I can say that there actually are quite a few methods here that I find really helpful (in between numerous native API duplicates). Pretty much all of them are connected with the iteration capabilities, highly limited in native API. Other than that, methods for object assignment (remember native Object.assign()), merging, cloning and differentiating (from Collection methods) are very useful too.

Seq

Seq is a collection of prototype methods, centered around one functionality - Lodash value wrapper (_())! With such wrapper in place, you can omit the repeating _. and use your methods directly on your value (e.g. _(1).add(1)) - now that’s something! And, imagine how good can it feel to use such wrapper, especially with some chainable methods! Of course, you should use it with care, as creating many Lodash wrappers can result in high memory usage, and thus - lower performance. Other functionalities from seq collection are meant to be used with mentioned wrappers.

String

Beyond providing standard, native API copies, methods from string collection cover some pretty useful capabilities. I’m mainly talking about converting between different case types, which may seem really easy but isn’t implemented natively, requiring developers to create quite a big boilerplate for such simple cases. 😉 Of course, there are also methods for swapping letters, string-array conversion, regex integration and more, but still… it’s not really something that would require much effort in plain JS.

Util

The last important collection of methods in Lodash is called utils. And, as the name suggests, there isn’t really any rule that groups all this stuff together. Thus, there’s almost no method that has its direct native equivalent… which is good. Here, beyond all the useful stuff, there are some methods that make me smile, e.g. [_.noop()](https://lodash.com/docs/4.17.11#noop) with all it does is simply returning undefined. You wanted to know how far you can go with using Lodash - here’s the answer. 🙃

And still… Lodash is awesome!

I may repeat myself, but I really want you to understand the point that I’m making. I’m not really criticizing Lodash for any additional functionality it provides - even if this is some kind of native API duplicate! With modular structure, there’s no real point to do that - you only use the parts of the library you want and nothing more. And, Lodash with its intuitive API and convenience (that’s a very important word here) it provides makes development experience so much more enjoyable. And I fully admit that. But, over-reliance (hello there _.add() and _.noop() 😉) on any kind of library, allowing it to dictate the structure of your project, or limit your use of native solutions (when easily available) is not good. But, it means a failure of the library’s user rather than the library itself. So, yeah, Lodash is awesome!

Thoughts?

So, what do you think of Lodash and its API? Do you agree with the statements made in this post? And, do you like the post itself? If so, please share it! Also, leave your opinion below through a reaction 🤯 or a comment! Also, consider following me on Twitter, on my Facebook page and signing up for my newsletter! Thanks for reading this one through and I’ll see you in the next one! ✌