11 ms·
No Lodash
- lake-view 4y agoMissed a golden opportunity to call this Nodash.
- afavour 4y agoHaving 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.
- stolenmerch 4y agoLooks 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."
- afavour 4y agoLooks like the v5 deprecation is only the separate modules. "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.
- CharlesW 4y ago> 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?
- e1g 4y agoYou 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.
- andrewstuart2 4y agoLibraries 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.
- mlajtos 4y ago> The API matters, and readability matters. Exactly, lodash should be part of the language. https://github.com/mlajtos/es1995 https://github.com/mlajtos/es1995
- lcvriend 4y agoI 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.
- SkyPuncher 4y agoLodash 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.
- shortcake27 4y agoIn 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.
- phailhaus 4y agoI 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.
- afavour 4y agoMaybe 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.
- nightski 4y agoI hope lodash does not deprecate because I prefer non-instance methods personally.
- afavour 4y agoSemver means you'd always be welcome to use the old versions of the library if you wished.
- nightski 4y agoI understand Semver, but then I'd get no new updates and for no good reason. It doesn't make any sense to remove it.
- afavour 4y agoThey'd be able to publish updates to older versions of the library if they so wished. Like v2.6.0 -> v3.0.0 deprecates _.fill(), then a security fix comes along so they publish 3.0.1 2.6.1 > It doesn't make any sense to remove it. 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.
- deleted 4y ago[deleted]
- jerf 4y agoWould 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.
- andrewla 4y agoYes -- 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".
- Kerrick 4y ago> 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/ https://youmightnotneedjquery.com/ in a good way.
- dchest 4y agoHere's https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders...
- Mimmy 4y agomaybe a dumb question but isn't lodash already implemented entirely in vanilla js? wouldn't the equivalent be just looking at the lodash source code?
- whstl 4y ago1. By "already implemented entirely in vanilla js" you mean that there are native functions for everything? If so, no, it's not entirely useless. Check the article for examples where it isn't. 2. No, for most things there are several differences between what is on Lodash source code and the current native-Javascript implementation. Check this: https://news.ycombinator.com/item?id=35057549 https://news.ycombinator.com/item?id=35057549
- strict9 4y agolodash and other utility libraries can be helpful when backend devs who don't usually work in JS need to do something complicated on the front end. That said, if focusing on front end dev work I think it removes knowledge of underlying apis which can be counterproductive in the long run. If you have enough knowledge to achieve in plain JS what is done with lodash, you are better set up for success when given a problem not yet solved in your code base or stackoverflow.
- motogpjimbo 4y agoThis is true for backend frameworks too. In the PHP world, Laravel contains many helper functions that uselessly duplicate functionality already available in the standard library. Not only is this a waste of effort from the framework's author, it also unhelpfully silos some developers into Laravel-specific knowledge. I had a colleague who had worked professionally as a Laravel developer for several years but then failed a job interview because he'd literally never written a vanilla PHP script and had no idea how to go about it.
- xlii 4y agoI’d still use Lodash functions over the native ones for chaining [1]. 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/ https://docs-lodash.com/v4/chain/
- denysonique 4y agohttps://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore#array https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders... seems to be a more readable alternative to this website.
- moomoo11 4y agoTo be fair a lot of these utility functions are easy to implement without the dependency. And one can install only the individual lodash functionality that’s required. Personally I’d do this in the node/js ecosystem because everyone does it and why not? It’s battle tested. I work primarily in Go so I’m used to writing my own utilities for many things. It isn’t that complicated and end of the day it’s just basic programming.
- feoren 4y ago> Personally I’d do this in the node/js ecosystem because everyone does it and why not? It’s battle tested. When almost all software is completely terrible, "everyone does it" is not a compelling reason to do anything. And this approach is indeed battle tested, in battles that were abject massacres (see left-pad).
- watwut 4y agoWell, I just dont think that "almost all software is completely terrible" is true. In particular, many libraries are actually good or at least better then own half-baked solutions you never had time to test thoroughly.
- Zetice 4y agoThere’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.
- HeavyFeather 4y agoSpeed 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: https://github.com/angus-c/just https://github.com/angus-c/just
- Zetice 4y ago> 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.
- boredtofears 4y agoIt's not that small: https://bundlephobia.com/package/lodash@4.17.21 https://bundlephobia.com/package/lodash@4.17.21
- Zetice 4y agoPer your citation, at 875 kB/s it takes 28ms to download. I'm gonna leave that in the "small" category for now, considering 516.25 kB/s is about what Cuba averages on mobile, ranked last in the world. [0] [0] https://www.speedtest.net/global-index https://www.speedtest.net/global-index
- Rumudiez 4y agoLodash 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 [1] https://ramdajs.com/ https://ramdajs.com/
- beardedetim 4y agoCannot 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.
- ASalazarMX 4y agoReading 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.
- recursive 4y agoWhat is "pipe"? Surely you're not referring to the bitwise-or operator `|`?
- dvlsg 4y agoRamda has a composition (left to right) function named pipe: https://ramdajs.com/docs/#pipe https://ramdajs.com/docs/#pipe 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.
- Rumudiez 4y agoIt’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
- thirdvect0r 4y agolodash is great because you can import @types/lodash into your TS project and have great inferred types from things like _.uniqBy or _.omitBy; without such support, vanilla JS "equivalents" are just not useful
- rambojohnson 4y agoI never understood the conviction behind these silly purist initiatives lol, especially on the job, in the real world.
- whstl 4y agoWhy do you assume this is a "purist initiative", rather than what it says it is on the tin ("a catalog" of alternative implementations)?
- wdhilliard 4y agoI think it is unclear why you would write a list of alternatives to lodash unless you are trying to make the case that using these implementations is better than using the lodash functions. There is also a pretty long history of "you don't need to use lodash" articles and sites arguing that lodash is a crutch or simply bad.
- whstl 4y agoIt's not really unclear. It is for people to learn more things, update their knowledge and use the library piecemeal if necessary. It is always up to the person learning to make a decision on what to do afterwards.
- rafaelturk 4y agoWhy? Lodash evolved to quite stable status with predictable results.
- deleted 4y ago[deleted]
- toastal 4y ago> You need to enable JavaScript to run this app. What app? Is this an app? If it is, why didn’t you name it or tell me what I’m missing out on instead of using the default some framework spits out. [temporarily enables JS for the site] Oh, it’s just static informational content that should have good SEO and TUI-compatibilty but missed the mark. Don’t need Lodash? How about this page doesn’t need JavaScript! These code examples are the perfect semantic use case for the <details> + <summary> elements. (And I love JavaScript, but for contexts that need it like applications)
- atsjie 4y agoI agree, the days of chaining lodash functions together are pretty much behind us. But I still like lodash, particularly for functions like these: - words - kebabCase / startCase / snakeCase - partition - debounce Basically the more advanced functions for which no readily available alternative exists?
- haswell 4y agoThe title needs an update. The current title is actively misleading and is affecting the comments. The content does not claim that you should not use Lodash. It only presents alternatives to Lodash functions. The actual title "Lodash Replacements" is far more accurate by reflecting what the page contains, and doesn't invite misinterpretations or ideological responses.
- hot_gril 4y agoIf someone on my team imports Lodash and uses it all over the place to significantly reduce our LoC, fine by me. What makes it annoying is when someone adds that whole dep just to use it once, or for something ES6 already has (e.g. map). Same with Axios instead of fetch.
- wdhilliard 4y agoIt is really annoying (and in my opinion, almost misleading) that named imports from lodash do not tree shake. That said, you still can import individual modules without having to use the entire library. At my company we had to turn on linting rules to make sure our developers do not continue to import the entire library. Or even worse, import '_'
- deleted 4y ago[deleted]
- mark_and_sweep 4y agoThe back button doesn't work on function detail pages. (Using Firefox 110 on Android.)
- QuelqueChose 4y agoAm I misreading or are there no translations to pure JS available specifically for collections? The ease of being able to do "what i think I want to do in my head" with a collection using a one-liner often is the primary reason I'd use anything Lodash-y in the first place. The fact that I can import those methods directly to my projects and forget about the guilt of bundling the rest of the library really have kept Lodash top of mind for me for years. I have found that not so much when writing my own projects and tinkering, but specifically for "real" work (at my job) is when I have to deal with iterating over collections all the time. Anything less readable than Lodash is just overly annoying thanks to JS verbosity. Most people wouldn't remember to pull these methods out of a utils directory that we maintain simply for the purpose of ignoring packages like Lodash. By a collection, I'm talking about an array of objects that follow the same pattern.
- joeframbach 4y agoWhat does this provide that https://youmightnotneed.com/lodash/ https://youmightnotneed.com/lodash/ doesn't?
- FlacoJones 4y agoWhere is .cloneDeep? That alone is mainly what I use lodash for. Even though JS is pass by value, if you pass an object, the other nested objects will still be references to its predecessor.
- contextnavidad 4y agoWe used `cloneDeep` heavily at a previous role, it isn't particulary fast - so be careful if you cloning very big objects (1mb+). There are faster options out there such as https://github.com/davidmarkclements/rfdc https://github.com/davidmarkclements/rfdc or even https://developer.mozilla.org/en-US/docs/Web/API/structuredClone https://developer.mozilla.org/en-US/docs/Web/API/structuredC...
- phist_mcgee 4y agoTechnically it's called call-by-sharing.
- moogly 4y agoI like `fast-copy`. Never had an issue with that.
- moogly 4y agoDidn't see anyone mentioning Lodash's IMO biggest flaw: being null/undefined safe. As in `_.map(undefined, (item) => item)` returning an empty array. Promotes sloppy code and interfaces really badly with TypeScript.
- iKlsR 4y agoFun exercise, use cgpt or copilot to convert the descriptions into code and then roll your own then check correctness and benchmark cgpt, your own, author's own and lodash.