As in, I want actual zero dependencies, not even the library itself. The reason: I never want these to randomly update.
Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
21–30 of 88 posts
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#22[deleted]
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#23What 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.
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#24What 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.
You'd miss out on CVEs because you don't use the common dependency paradigm.
You'd also miss out on bug fixes if you are not detecting the bug itself.
Help me understand because I'm with you on less dependencies but this does feel a bit extreme.
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#25Earlier 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
Absolutely agree. I also hate that empty arrays are true, which is different from other languages. But I agree that it's better to face the reality of the language than create a function that evaluates [] to false. It trains you a bad habitnand some day that will cause you to introduce a bug.
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
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#26What 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.
OOC, what is the benefit of having a "library" that requires such manual labor to maintain and upgrade? You'd miss out on CVEs because you don't use the common dependency paradigm. You'd also miss out on bug fixes if you are not detecting the bug itself. Help me understand because I'm with you on less dependencies but this does feel a bit extreme.
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#27Earlier quoted context omitted.
OOC, what is the benefit of having a "library" that requires such manual labor to maintain and upgrade? You'd miss out on CVEs because you don't use the common dependency paradigm. You'd also miss out on bug fixes if you are not detecting the bug itself. Help me understand because I'm with you on less dependencies but this does feel a bit extreme.
Why would small functions like "difference", "groupBy", "flatten", etc. have CVEs and require bug fixes? Implementing those correctly is a one and done thing
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#28Earlier quoted context omitted.
Why would small functions like "difference", "groupBy", "flatten", etc. have CVEs and require bug fixes? Implementing those correctly is a one and done thing
You'd be surprised: https://positive.security/blog/lodash-ramda-underscore-vulne...
Re: Show HN: SuperUtilsPlus – A Modern Alternative to Lodash
#29Earlier quoted context omitted.
Absolutely agree. I also hate that empty arrays are true, which is different from other languages. But I agree that it's better to face the reality of the language than create a function that evaluates [] to false. It trains you a bad habitnand some day that will cause you to introduce a bug.
> 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
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 to clarify, I'm not saying one is better than the other. I just prefer how it works in other languages like Python. But I still would rather work with the JS language properties, than import a library that changes how I test for empty arrays.