Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

github.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#51

Post by PUSH_AX »

dcsan wrote: post #31
williamdclt wrote: post #9

Earlier quoted context omitted.

I agree with the author that it’s almost never what you want. But I agree with you that it’s the reality of the platform, ignoring it will cause its own problems. I’d surface the footgun rather than trying to pretend it’s not there: isNonArrayObject and isObjectOrArray, or something like that

your option is a bit more verbose but definitely more clear. confusing the underlying definitions of the language itself will lead to problems later.

Will it? Will it really?

I’ve been writing JS for so long I’ve forgotten all these language quirks, I feel like it’s fair for most people, these language choices are kind of meaningless in day to day, what’s meaningful is a function returning things that will make sense to most people. Or at least have two functions, languageStrictIsObject()

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#52

Post by bythreads »

gcmeplz wrote: post #32
jokull wrote: post #19

I recommend https://remedajs.com/ - they're always making the types more accurate too. Like groupby has nonempty lists.

The types look great on remeda, but one thing that looks intriguing about SuperUtilsPlus is the focus on being tree-shakeable. Lodash's lack of tree-shake-ability is a drawback to using lodash on the frontend. edit: the types on remeda look great though! If I were doing a backend-only NodeJS project, I'd be super tempted to test it out.

Just import what you use for lodash?, the theres not need for a treeshake situation?

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#53

Post by bryanrasmussen »

7bit wrote: post #12
bryanrasmussen wrote: post #10

Earlier quoted context omitted.

libraries of this sort, especially in JavaScript, often exist to enforce a more reasonable mental model rather than the model baked into the language.

I understand that. I just don't think that it is a good habit. Instead of just learning the languages and it's quirks now you form a bad habit and start to rely on one dependency for all your projects.

this is generally the view I have on these sorts of things as well, although I must admit that my views are often out of step with what everybody else I work with feel on the matter.

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#55

Post by programmarchy »

yoz-y wrote: post #21

What I’d like is a utility library like this, but instead of it being an actual library, be it some utility that generates a single file with exports of the few functions I need. Even just something that would make copy pasting them easier. As in, I want actual zero dependencies, not even the library itself. The reason: I never want these to randomly update.

shadcn distribution model for utils is a good idea. i wanted something for react hooks as well and was surprised that didn’t seem to exist either.

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#56

Post by nothrabannosir »

7bit wrote: post #29
williamdclt wrote: post #25

Earlier quoted context omitted.

> I also hate that empty arrays are true, which is different from other languages I don’t mind that actually! I don’t think I have much use cases for “empty array is semantically different from non-empty”. Usually I find null/undefined are better choices, an empty array is just a normal array, I don’t expect it to be handled differently

What do you think about empty strings being falsy in most languages including js? Null/undefined is a better choice, but there's many occasions where you do not have the power of choice. For example with document.querySelectorAll, which returns an empty array if nothing is found. The simple thing to do is to just check for it's length or just iterate over it's nodes, but still. I prefer empty arrays being falsy. Just…

Akshually, implicitly casting any non Boolean type to true or false is no better than implicitly casting “0” to 0. :) B-)

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#57

Post by mystifyingpoi »

acbart wrote: post #23
yoz-y wrote: post #21

What I’d like is a utility library like this, but instead of it being an actual library, be it some utility that generates a single file with exports of the few functions I need. Even just something that would make copy pasting them easier. As in, I want actual zero dependencies, not even the library itself. The reason: I never want these to randomly update.

Couldn't you just pin a specific version dependency? My brain says there's some way to also pin to a hash, but that would require googling and I'm on mobile.

Pinning is a good strategy (I'd say that it should be the default one), but depending on your level of paranoia (think left-pad), you might consider just downloading the lib as it is, and storing it in source control forever.

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#58

Post by mystifyingpoi »

nodewrangler wrote: post #37
acbart wrote: post #23

Earlier quoted context omitted.

Couldn't you just pin a specific version dependency? My brain says there's some way to also pin to a hash, but that would require googling and I'm on mobile.

The problem is that even if you pin to a version, at some point you’ll need to update node, typescript, or some other package, and then if this package doesn’t update, then you may have to migrate from it to something else. While js tries to enforce backwards compatibility, and npm, etc. help with the complex landscape, in practice with node, typescript, etc., even with LLMs helping, it can be a pita and hours or day…

> at some point you’ll need to update node, typescript, or some other package

I experienced both sides of this discussion (project that always pulled :latest disregarding any kind of versioning, and project that had node_modules commited inside the repo) and both extremes suck, but I lean towards the second one. I'll totally take a few days of pain over not knowing whether prod will work today or not.

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#59

Post by skydhash »

fsloth wrote: post #48
yoz-y wrote: post #21

What I’d like is a utility library like this, but instead of it being an actual library, be it some utility that generates a single file with exports of the few functions I need. Even just something that would make copy pasting them easier. As in, I want actual zero dependencies, not even the library itself. The reason: I never want these to randomly update.

Nobody wants anything _ever_ to ”randomly update”. Why this is the default setting on so many development setups boggles my mind. I really havent figured out why professional systems insist running on the bleeding edge - it’s your feet are bleeding here I believe. 10 year … 15 year old code is generally excellent if you know it through and thorough.

As my experience grows, I'm getting fonder of stances like Debian or Common Lisp, which favors stability. Once you've solved a problem, it's not fun having your foundation morphs under you for no other reasons than bundling features and security updates.

Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash

#60

Post by uwemaurer »

dhax_or wrote: post #40
_1tan wrote: post #14

We use es-toolkit to replace Lodash - how would you compare your library? We just migrated a React app with around 500k LOC and this worked quite well and flawless.

I've not used es-toolkit but from what I see you get lower bundle size, typescript support and a better performance with our library. I will be releasing the the benchmark soon enough so do watch the repository if you can

I use es-toolkit. It is fully in Typescript. Every function can be imported without any extra overhead, for simple functions it just adds a few bytes then to the bundle. I doubt "better performance" since most helpers functions are just tiny and there is no room for significant improvements.

So I think trying to be better here is pointless, better focus on offering more helpful utility functions which might be missing in es-toolkit

Post reply on HN