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.
Unless you were importing individual functions.
Also we did have a mix of things like import _ from ‘lodash’ and import foo from ‘lodash/foo’, etc
I believe the post you're replying to is referring to what I originally referred to (doing something like `const throttle = require('lodash/throttle')`, which you would install lodash normally for `npm install lodash`).
EDIT: And to be a bit pedantic, importing single modules is not really treeshaking. You're literally just importing and including the entirety of single modules.
I'd say that's basically a poor man's treeshaking because you're telling it you only want that module and its dependencies. Not it trying to figure it out for you.
All of this crud builds up, and you end up with 25MB bundles and slow SPAs.
With that approach fallible humans carry less risk.
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.
Activity on master really died down mid-2017 [1]
And the most recent closed PR is jdalton this year (Jan 4 '23) saying he's not looking to expand lodash [2]
[1] https://github.com/lodash/lodash/graphs/contributors [2] https://github.com/lodash/lodash/pull/5575#issuecomment-1371...
It would actually be cool if lodash started deprecating functions like _.fill (via semver so nothing breaks, of course) someday.
3.0.1
2.6.1
It does. Once the native platform supports the functionality it's redundant to keep it around and makes it less clear to a developer that the library isn't required any more. I'd argue it doesn't make any sense to use it but I'm not going to tell you that you can't. It's possible to accommodate everyone.
I disagree. Keeping it in accommodates everyone (not just your needs). You are not forced to use it, or even bundle it. I use lodash-es w/ tree shaking as it is.
Why not? Until recently they were publishing individual packages for every single Lodash function. Publishing different versions that just do or do not exclude a single function is pretty simple by comparison. It seems like you want the project to hold itself back for no good reason.
Right. But we're talking about group that until recently maintained 281 separate packages. "much more burdensome" is a relative term here and publishing two versions simultaneously is absolutely not that burdensome.
> I prefer the lodash way of doing things, you don't. So don't use it, that is fine.
The solution I'm proposing lets you and me both use it exactly how we want to. I honestly find this debate to be quite baffling.
Why?
Sure but you can't filter in a map, or map in a filter.
So you can do both map and filter as part of a reduce or flatMap, but not either as part of the other. (You may be able to get close by doing ugly things in a map/filter that abuses the second and third arguments, but I don't think you can get a general map out of filter or vice versa, and you shouldn't do the kind of things you'd need to do to get close, just use flatMap.)
For example:
_.compact(array)
array.filter(value => !!value);
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.
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's the point of spending the time writing your own interface, implementation, and tests of every single util
I would not write tests for many of these, and the interfaces usually require no design because these are familiar functions like map, filter, etc, to most experienced developers.
I gave the main reasons answering your questions in my last post, and I think those reasons are powerful enough that I would consider using a lodash a mistake in most situations.
You are essentially making the "leftPad" argument, it's a kind of inverse "NIH" ethos: Why should you ever write your own anything when someone else has done it? And the answer, again, is the same: dependencies have a non-trivial cost.
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.
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.
0 lines of code is preferable to battle-tested code.
10 lines of code is preferable to 1000 if you don't need them.
Not always. Lodash's _.find is 5k. Why is something as simple as find so huge? It has a lot of magic. A lot of that magic provides safety though.
I don't recommend dropping lodash unless you can start using typescript.