I mean...sure? But this isn't very compelling when:
1. Many of these examples are just implementing the function (e.g., _.chunk). Yes, Lodash is written in Javascript, so yes, you can implement them yourself if you wanted.
2. Lodash is tree-shakeable, so if you import the functions you use directly, only those will be included in your JS bundle.
Just use Lodash, it's better than having to maintain your own hodgepodge of poorly documented and tested utility functions.
> 2. Lodash is tree-shakeable, so if you import the functions you use directly, only those will be included in your JS bundle.
I don't use Lodash, but recently began work on a project that does. I was surprised (along with the rest of the team) to find out that Lodash is not tree-shakeable by default. So if you do `import { debounce } from 'lodash';`, you're actually including the entirety of lodash in your bundle. More info here: https://lodash.com/per-method-packages
The recommended solution by the lodash team is to use `babel-plugin-lodash` (including a babel plugin to use less code? no thanks) or import the single modules directly like `import throttle from 'lodash/throttle';`. In the end, since we only used about 3 functions from lodash that were trivial to replicate, we just ditched lodash.
EDIT: There is also a `lodash-es` package with native ESM modules which may solve this issue for some. We avoided this also because it had implications with our toolchain.
For a few years I was opting to use the per-method packages from npm (`npm install lodash.pick`) but they just stopped being updated... https://www.npmjs.com/package/lodash.pick has not been updated in 7 years and is stuck at v4.4.0. I guess I missed the memo on that... and none of the npm packages have been deprecated to reflect the state of things.
Now going onto the lodash package on npm, that's listed as v4.17.21 and hasn't been published in over 2 years: https://www.npmjs.com/package/lodash
Maybe a better writeup would be "the Lodash functions you don't need to bother with any more". Like _.fill, which this article correctly states can just be replaced with Array.fill these days. But e.g. _.zip still has no equivalent.
It would actually be cool if lodash started deprecating functions like _.fill (via semver so nothing breaks, of course) someday.
The problem with these utility functions is that they're not chainable. It would also be nice if they made more use of Array.map or reduce rather than using for loops and mutating things. If I couldn't do it using a simple Array.map, reduce, filter or sort, I'd still use loadash or underscore if it was loaded.
I find these fairly comprehensive writeups to be useful, because even if you would never use the more complex replacements, it makes it easy to verify that yup this is really the best you can do with pure javascript, I'll use a library for these calls.
I would think that lodash would check to see if the browser supports the methods and then use those method natively instead of a polyfil. this is the approach jquery takes
The thing is that the JavaScript version is often more readable than the lodash one (unless you have a lot of experience with lodash of course).
For example:
_.compact(array)
vs
array.filter(value => !!value);
Most JavaScript programmers will immediately know what `array.filter(value => !!value)` does but many will have to lookup the lodash documentation to understand what `_.compact(array)` does.
That's a good example. I looked at the first example "chunk" where the replacement is just a "chunk" function in javascript, and I asked myself what the purpose of this is, why I would copy-and-paste this chunk function rather then importing it from lodash. I think this site would be much better if it only included examples where the vanilla JS version is actually more readable.
1. Functions that have equivalently terse native versions (fill, map, etc)
2. Function that have multi-line equivalents (chunk, zip, etc)
Yes you can _.map an object and you can't myObject.map but I prefer Object.[keys/values](myObject).map(...) but for something like _.chunk I absolutely prefer to use lodash. Maybe one day we will see a new major version of lodash that deprecates all the near-native versions of functions so you can still use them but your editors will do a strikethrough and the JSDoc for the function can steer you to the native version but there are still a lot of useful lodash functions.
> Lodash is tree-shakeable...
> Just use Lodash, it's better than having to maintain your own hodgepodge of poorly documented and tested utility functions.
There are good reasons not to:
- You don't want to add a build step to your project
- You don't want to introduce any additional knowledge burden on contributors to your code, other than knowing JS. Your "chunk" is the few lines of source code in your repo -- not an external thing with documentation you have to lookup.
- You don't want to deal with the security issues every dependency introduces
Let's specifically address this claim, which is often used in roll-your-own vs use-a-library debates:
> to maintain your own hodgepodge of poorly documented and tested utility functions
I feel, in this particular case, this argument is a straw man. The functions in question are basically 1-liners. The likelihood of bugs are low. The need for documentation is nil: the implementations self-document.
I don't think the idea is "if you need these 6 simple functions, use lodash, not vanilla JS". If you only need 6 simple functions, then writing them in house makes sense.
But suppose you already have usecases for lodash's more complex functions. It can make sense to use a library like lodash to fill in those functions rather than utilizing your own. And if you already have lodash available, you may as well use it for simple functions, too, rather than write your own.
> The functions in question are basically 1-liners.
No, they're not. The first one is not a one-liner. What's the point of spending the time writing your own interface, implementation, and tests of every single util that you end up needing, if you could just import lodash and move on?
I honestly haven't needed lodash in years. So much is built into JS now or very trivial to do. If I want to diff an array I don't create a diff function. I just diff it. Then there are things like fill, flatten, drop, etc, which are really just part of JS now.
TFA does not claim that you shouldn't use Lodash (the HN title is incorrect and misleading). It leaves it up to the reader to decide why they might not want to use Lodash and makes no arguments for or against such a stance.
What remains is a pretty useful overview that lets the reader see what each function is doing with emphasis on the how. It is presented as "if you wanna replace this, here's how".
If I'm not already familiar with Lodash and trying to decide whether or not to bring it in as a dependency, and see that all I need is a 1-2 liner in native JS, that's useful information. I might still conclude that Lodash is the right choice, but I think that when examined in the context of the broader industry, where 3rd party libraries are often unnecessary and sometimes actively unhelpful, I think such a page is useful.
Whether or not it's "compelling" will entirely depend on the problem you're currently trying to solve.
Introducing a supply chain vulnerability in order to import utility functions that any novice could write is a choice, I suppose. By the way, did you know it’s been seven years since left-pad?
Even if you have Lodash in your codebase, there are a bunch of functions it offers that have direct built-in analogues at this point, and I think it's still best to skip the library versions of those
Ironically I don't see all of those in this list. Maybe OP just assumes everyone already knows how not to use those
I was expecting more of a 'write your own implementation' kind of thing, but it's not really that.
For example, the replacement for _.concat() is really just advice on how to concatenate arrays in-line. In such cases, I think learning that a packaged function is not needed is pretty nifty.
This points at a larger problem: the junior developers who gleefully pull in tons of third party requirements which, as far as I can tell, is the supposed "senior" approach in javascript development.
Do you have any examples that show that `just` is more efficient than lodash? It doesn't even have a `chunk` implementation, so it's hard to say that it's better.
The "bloat" is the result of being battle tested. A slimmer implementation would cut out edge cases that I may or may not run into. If I use Lodash, I know I'm all set.
Would be nice to have some indication of the size of the replacement visible before I click, so we can scan down the page and get a sense of what is what.
That is, I'd love to see how many of the replacements look like
_.now() -> Date.now()
and how many of them are like
_.invert(object) ->
function invert(obj) {
const newObj = {};
for (const [key, value] of Object.entries(obj)) {
newObj[value] = key;
}
return newObj;
}
Also clicking through I see a lot of "when lodash was created this was necessary because X, but now we can Y". Kudos for including that. It is both informative and helps this not come off as an attack.
Yes -- this seems like it would be significantly more useful if it divided between "vanilla Javascript now supports this or similar functionality natively" vs. "if you're getting rid of lodash and use these functions, then you'll have to write your own variant, along with tests".
> Also clicking through I see a lot of "when lodash was created this was necessary because X, but now we can Y". Kudos for including that. It is both informative and helps this not come off as an attack.
Lodash gets so many things wrong I’d rather not see it in most projects. I appreciate a good utility library for JS projects but my go-to choice has to be Ramda[1]. Every function it exports is curried and works great with pipe which enables me to write highly reusable and composable functions in pointfree notation. I have never been as productive with lodash, and I find the functional style easier to read
if you enjoy functional programming and are looking for a utility library, ramda has been a joy. very very well thought out. being able to compose functions together and treat data as a stream of information being transformed is incredibly easy. it is also compatible with libraries which implement algebraic structures like fantasy land. coupled with the other r libs its quite fun to program with. just be careful as it gets hairy to read pretty fast if one doesn't understand all the functions that come into play...
Cannot recommend Ramda enough. It's a great utility belt to build your application with. Only downside is the pushback I always receive from the team when I try to introduce it.
Reading the insightful comments in this post, I see why accommodating JavaScript's inherent flaws has snowballed web development. You need to know concepts like tree-shaking (removal of dead code) to pick among 10 different libraries that mostly do the same in subtly different ways.
It's similar to the pipe operator seen in other languages (Elixir, F#, etc). There is a proposal to add a pipe operator to JS as well - still in early stages, though.
It’s for connecting functions together like a pipeline, the same as compose but the fn list is reversed. Lodash has something similar called chain, but that’s harder to extend and isn’t as portable as partially applied functions
Libraries like lodash/underscore don't get popular for no reason. The API matters, and readability matters. Sure, you can do these things without the library, but the readability suffers. Adding in the ability to chain these calls into a nice little readable "paragraph" of small single step data changing functions, there's significant value in the underscore and similar compatible libraries.
I am sure you are right. However, this does look very useful to me.
I am not a professional js developer but I do like to build dinky websites. I generally prefer not to bother with build steps or dependencies. For me it's preferable to have my own implementation of a function within the file or project I am working in. That way I can directly inspect what the function is doing, which is "more readable" to me.
Moreover, sometimes I need functionality that is similar but just a bit different from something that lodash does. This seems like a good resource to check for inspiration.
Lodash also handles "bad-types" in really graceful ways. In fact, it's almost the primary reason I use it.
For example, if you have a nullable array. In plain JS, you have to check the presences of the array, then run `find` (or whatever function). Lodash simply treats it like an empty array - returning nothing.
This is particularly handy in React where it creates clutter to have to check for the empty state.
In your nullable array example, you could just use optional chaining. There’s no need for lodash.
I personally feel this type of ultra-defensive programming where all types are assumed bad only harms you long run, adding complexity where it isn’t necessary to solve problems that don’t exist, and swallowing errors making it harder to debug. Exceptions exist for a reason.
When I switched to TS it was a great incentive to ditch lodash because it was munging all my types. This in turn simplified my code as it made me aware of unnecessary guards, coercions, and errors that lodash was swallowing.
Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies. First it was direct DOM manipulation without jQuery getting in the way, now it's direct JS calls without a utility library getting in the way. The ecosystem really has come a long way.
It's also worth noting that lodash lets you import individual functions, e.g.
import throttle from 'lodash/throttle'
so even when you do need a utility function you can avoid pulling the entire library into your code.
Looks like this will be removed in v5. "For example, throttle uses debounce internally. In a project using both methods from the main lodash package, throttle will import the same debounce module as any code that imports debounce directly, so only one copy of debounce will wind up in a webpack bundle."
> Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies.
Assuming you're working on commercial products, how do you decide when to move to new-ish native functions? For example, do you log feature detection for the function a month or two prior to the planned change?
You probably have HTTP access logs and can use that to run your own calculations based on UserAgent and caniuse. We are in enterprise, and 90% of our users are on evergreen browsers, and the next 9% have a browser version from the last 18 months. For the last minority, we conditionally include a polyfill from polyfill.io
“Browser support” is not an issue anymore unless you do something cutting edge, sell to regulated industries like healthcare, or serve many users in China/Africa et al.
There’s an entire category of developer that concerns themselves with stuff like this, and I wonder if they know you can be a successful dev and not care one bit about taking your imports this seriously, and instead just grabbing libraries from npm.
It strikes me as the difference between knowing why your role exists and not realizing you deliver organizational value, over engineering perfection.
An important role of developers is knowing which tools exist and what can be used to provide value.
To use Lodash, a developer needs to know what is available there in the first place. You're taking it for granted, but everyone, you included, had to study its documentation and memorize which functions were there, even if it was only to "look it up" later.
Someone like you could have said a few years ago about Lodash: "why do I need this stupid library, I will just use for loops everywhere, like I learned in college. They get the job done and my role is to provide value, not to care about libraries or code reusability".
With this website, it's the same thing: it's there to teach you which things in Lodash aren't needed anymore and which are. Then it is up to the developer to use what's best. Not everything in the internet is prescriptive.
Blind dogmatism shouldn't have a place in our profession.
That's kind of my point, though? Caring about "blind dogmatism", one way or another, is not required to be a highly effective software dev.
For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first.
I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness.
And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.
Speed brings value. Loading dash without optimizing it carries a huge weight. Weight can slow down users. Users leave the cart before completing a purchase.
Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`.
On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just:
> Loading dash without optimizing it carries a huge weight.
This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
Considering that a bigger engineering and social problem in the Javascript world is the plague of micromodules of dubious provenance, arguing against using solid and trustworthy utility libraries is counterproductive, or even symptomatic.
Using libraries like lodash, instead of adding 12 left-pads of different authors to the dependencies manifest, is an improvement over the status quo.
You can be a successful dev without doing a good job. Many people just want to do a good job and don't particularly care about being "successful."
It's not that your coworkers don't know you can get away with doing a bad job, it's that they're not motivated by the same things that you are.
It's true that in some contexts, throwing npm libraries at the wall to see what sticks is delivering organizational value. In many others, it's negative value.
That's the point; there is no "successful dev" without "doing a good job".
The folks who don't care about being "successful" are not "good devs", because they're not clear about why their job exists in the first place. You don't really get to define success for your role without your organization's input, and when you overly focus on the engineering to the exclusion of delivering value, you are not acting as a "good dev".
Readit News
1. Many of these examples are just implementing the function (e.g., _.chunk). Yes, Lodash is written in Javascript, so yes, you can implement them yourself if you wanted.
2. Lodash is tree-shakeable, so if you import the functions you use directly, only those will be included in your JS bundle.
Just use Lodash, it's better than having to maintain your own hodgepodge of poorly documented and tested utility functions.
I don't use Lodash, but recently began work on a project that does. I was surprised (along with the rest of the team) to find out that Lodash is not tree-shakeable by default. So if you do `import { debounce } from 'lodash';`, you're actually including the entirety of lodash in your bundle. More info here: https://lodash.com/per-method-packages
The recommended solution by the lodash team is to use `babel-plugin-lodash` (including a babel plugin to use less code? no thanks) or import the single modules directly like `import throttle from 'lodash/throttle';`. In the end, since we only used about 3 functions from lodash that were trivial to replicate, we just ditched lodash.
EDIT: There is also a `lodash-es` package with native ESM modules which may solve this issue for some. We avoided this also because it had implications with our toolchain.
Now going onto the lodash package on npm, that's listed as v4.17.21 and hasn't been published in over 2 years: https://www.npmjs.com/package/lodash
Now the lodash package on github, the latest release is listed as v4.0.0 from 2016: https://github.com/lodash/lodash/releases
There have been no commits to the main branch on github in almost 2 years: https://github.com/lodash/lodash/commits/master
I consider lodash to be deprecated at this point, and will always go for a lightweight function pulled from somewhere like SO or No Lodash.
It would actually be cool if lodash started deprecating functions like _.fill (via semver so nothing breaks, of course) someday.
For example:
vs Most JavaScript programmers will immediately know what `array.filter(value => !!value)` does but many will have to lookup the lodash documentation to understand what `_.compact(array)` does.1. Functions that have equivalently terse native versions (fill, map, etc)
2. Function that have multi-line equivalents (chunk, zip, etc)
Yes you can _.map an object and you can't myObject.map but I prefer Object.[keys/values](myObject).map(...) but for something like _.chunk I absolutely prefer to use lodash. Maybe one day we will see a new major version of lodash that deprecates all the near-native versions of functions so you can still use them but your editors will do a strikethrough and the JSDoc for the function can steer you to the native version but there are still a lot of useful lodash functions.
There are good reasons not to:
- You don't want to add a build step to your project
- You don't want to introduce any additional knowledge burden on contributors to your code, other than knowing JS. Your "chunk" is the few lines of source code in your repo -- not an external thing with documentation you have to lookup.
- You don't want to deal with the security issues every dependency introduces
Let's specifically address this claim, which is often used in roll-your-own vs use-a-library debates:
> to maintain your own hodgepodge of poorly documented and tested utility functions
I feel, in this particular case, this argument is a straw man. The functions in question are basically 1-liners. The likelihood of bugs are low. The need for documentation is nil: the implementations self-document.
But suppose you already have usecases for lodash's more complex functions. It can make sense to use a library like lodash to fill in those functions rather than utilizing your own. And if you already have lodash available, you may as well use it for simple functions, too, rather than write your own.
No, they're not. The first one is not a one-liner. What's the point of spending the time writing your own interface, implementation, and tests of every single util that you end up needing, if you could just import lodash and move on?
What remains is a pretty useful overview that lets the reader see what each function is doing with emphasis on the how. It is presented as "if you wanna replace this, here's how".
If I'm not already familiar with Lodash and trying to decide whether or not to bring it in as a dependency, and see that all I need is a 1-2 liner in native JS, that's useful information. I might still conclude that Lodash is the right choice, but I think that when examined in the context of the broader industry, where 3rd party libraries are often unnecessary and sometimes actively unhelpful, I think such a page is useful.
Whether or not it's "compelling" will entirely depend on the problem you're currently trying to solve.
Ironically I don't see all of those in this list. Maybe OP just assumes everyone already knows how not to use those
For example, the replacement for _.concat() is really just advice on how to concatenate arrays in-line. In such cases, I think learning that a packaged function is not needed is pretty nifty.
Here's the one you referenced, lodash.chunk: https://unpkg.com/lodash.chunk – 140 lines after removing comments and whitespace.
That's pretty small compared to a lot of the lodash utilities. Try spot-checking a few on unpkg.
I prefer angus's `just` utilities: https://github.com/angus-c/just
The "bloat" is the result of being battle tested. A slimmer implementation would cut out edge cases that I may or may not run into. If I use Lodash, I know I'm all set.
Deleted Comment
Deleted Comment
That is, I'd love to see how many of the replacements look like
and how many of them are like Also clicking through I see a lot of "when lodash was created this was necessary because X, but now we can Y". Kudos for including that. It is both informative and helps this not come off as an attack.It reminds me of https://youmightnotneedjquery.com/ in a good way.
[1] https://ramdajs.com/
It's similar to the pipe operator seen in other languages (Elixir, F#, etc). There is a proposal to add a pipe operator to JS as well - still in early stages, though.
I am not a professional js developer but I do like to build dinky websites. I generally prefer not to bother with build steps or dependencies. For me it's preferable to have my own implementation of a function within the file or project I am working in. That way I can directly inspect what the function is doing, which is "more readable" to me.
Moreover, sometimes I need functionality that is similar but just a bit different from something that lodash does. This seems like a good resource to check for inspiration.
Exactly, lodash should be part of the language. https://github.com/mlajtos/es1995
For example, if you have a nullable array. In plain JS, you have to check the presences of the array, then run `find` (or whatever function). Lodash simply treats it like an empty array - returning nothing.
This is particularly handy in React where it creates clutter to have to check for the empty state.
I personally feel this type of ultra-defensive programming where all types are assumed bad only harms you long run, adding complexity where it isn’t necessary to solve problems that don’t exist, and swallowing errors making it harder to debug. Exceptions exist for a reason.
When I switched to TS it was a great incentive to ditch lodash because it was munging all my types. This in turn simplified my code as it made me aware of unnecessary guards, coercions, and errors that lodash was swallowing.
It's also worth noting that lodash lets you import individual functions, e.g.
import throttle from 'lodash/throttle'
so even when you do need a utility function you can avoid pulling the entire library into your code.
"lodash/throttle" loads throttle.js in the lodash package.
"lodash.throttle" loads index.js in the lodash.throttle package.
The latter is being deprecated but not the former.
Assuming you're working on commercial products, how do you decide when to move to new-ish native functions? For example, do you log feature detection for the function a month or two prior to the planned change?
“Browser support” is not an issue anymore unless you do something cutting edge, sell to regulated industries like healthcare, or serve many users in China/Africa et al.
It strikes me as the difference between knowing why your role exists and not realizing you deliver organizational value, over engineering perfection.
To use Lodash, a developer needs to know what is available there in the first place. You're taking it for granted, but everyone, you included, had to study its documentation and memorize which functions were there, even if it was only to "look it up" later.
Someone like you could have said a few years ago about Lodash: "why do I need this stupid library, I will just use for loops everywhere, like I learned in college. They get the job done and my role is to provide value, not to care about libraries or code reusability".
With this website, it's the same thing: it's there to teach you which things in Lodash aren't needed anymore and which are. Then it is up to the developer to use what's best. Not everything in the internet is prescriptive.
Blind dogmatism shouldn't have a place in our profession.
For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first.
I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness.
And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.
Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`.
On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just:
https://github.com/angus-c/just
This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
Using libraries like lodash, instead of adding 12 left-pads of different authors to the dependencies manifest, is an improvement over the status quo.
It's not that your coworkers don't know you can get away with doing a bad job, it's that they're not motivated by the same things that you are.
It's true that in some contexts, throwing npm libraries at the wall to see what sticks is delivering organizational value. In many others, it's negative value.
The folks who don't care about being "successful" are not "good devs", because they're not clear about why their job exists in the first place. You don't really get to define success for your role without your organization's input, and when you overly focus on the engineering to the exclusion of delivering value, you are not acting as a "good dev".
Dead Comment
I like Elixir pipelines so this is equivalent. I suppose it depends on preference if someone chain or not.
[1]: https://docs-lodash.com/v4/chain/