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

71–80 of 88 posts

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

#71

Post by ryancnelson »

epolanski wrote: post #68
ryancnelson wrote: post #41

Earlier quoted context omitted.

No I’m asking a commercial that pops up in what I’m watching and says “ask your doctor if ciallis is right for you.” and gives no context but someone washing their tesla.

To use your analogy, this is more of "Show HN: Cialis - A modern alternative to Viagra". You either care about Viagra and read or move on.

the irksome bit was this: lodash's page, first sentence, says "A modern JavaScript utility library delivering modularity, performance & extras."

this github's readme says "alternative to lodash". other than being named "superutilsplus", someone who clicked on it would need to then go google for lodash to see it's another js utilities kit, to then figure out they don't care.

I stopped professional javascript development when i stopped having an office next to Ryan Dahl at Joyent, so, yeah i haven't cared for about a decade. Thanks for explaining about atoms, though, my esteemed chemists.

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

#72

Post by fsloth »

chrisweekly wrote: post #65
fsloth wrote: post #48

Earlier quoted context omitted.

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.

CVEs are a thing. If vulnerabilities are discovered in your dependency graph, choosing to ignore them can have severe consequences.

I don’t believe anything I wrote above promotes the idea of ignoring vulnerabilities as a standard procedure.

CVE database is an excellent way to be informed about vulnerabilities and there are services to automatically map CVE reports to code bases.

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

#73

Post by rafram »

insin wrote: post #50

The published version appears to be CommonJS only: $ node index.mjs import { isString } from 'super-utils-plus' ^^^^^^^^ SyntaxError: Named export 'isString' not found. The requested module 'super-utils-plus' is a CommonJS module, which may not support all module.exports as named exports. You might also need to update some of your type checks to handle wrapper objects like new String() - Object.prototype.toString.cal…

> You might also need to update some of your type checks to handle wrapper objects like new String()

There’s genuinely never a reason to use new String(). You should treat non-primitive String instances as bugs.

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

#74

Post by rafram »

ivanjermakov wrote: post #8
7bit wrote: post #7

> Like isObject([]) returning true - arrays aren't objects in my mental model. Correct me if I am wrong, but Array factually are JS objects and "[] instanceof Object" is true. Fair enough if that does not fit your mental model, but I would not use any library that treats facts like opinions.

Distinction is tricky since you can use indexing on plain objects, e.g. const foo = {}; foo[0] = "bar";

Right. For the purposes of standard library functions that operate on array-like objects,

  { length: 1, 0: "item" }
is an array.

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

#75

Post by 7bit »

nothrabannosir wrote: post #69
7bit wrote: post #67

Earlier quoted context omitted.

No better based on what criteria? In what language? This is typical in Python and done even by core-devs. It is how the language was designed and it was designed to support that.

In the "akshually" sense. "Zen of programming" (or "I'm smart because I use the word monoid unironically"). "If is an anti pattern", "null values are an anti pattern", "`string' is an anti-type", "util libraries are an anti pattern", etc. And of course "boolean is an anti type" but let's not get into that. :D (Nor into the value of "idiomatic python" as an argument on healthy programming habits....)

Ah got it. Based on personal opinion. Thanks for explaining.

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

#76

Post by sethaurus »

thih9 wrote: post #62

About pain points / feature requests: Is there an idiomatic way to duplicate a hash while replacing one of its values, preferably something that supports nesting? Whenever I work with react and immutable structures, this comes up and I hack something simple. I don’t do FE on a regular basis though so my perspective may be skewed.

These days that's pretty well-supported in the base language:

    const updated = { ...existing, someKey: someNewValue };
You mention nesting. That starts to look messier:

    const updated = { ...existing, someKey: { ...existing.someKey, ...someNewValue } };
There's a whole cottage industry of little libraries to make this ergonomic/fast in the general case (copying immutable objects with nested changes). `immer` is a popular choice. But the reality is that it gets complicated to do this generically; in my view it's usually better to just use the base language where possible, even if it means sprouting some util functions for the various kinds of updates you end up doing.

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

#77

Post by dschuessler »

7bit wrote: post #7

> Like isObject([]) returning true - arrays aren't objects in my mental model. Correct me if I am wrong, but Array factually are JS objects and "[] instanceof Object" is true. Fair enough if that does not fit your mental model, but I would not use any library that treats facts like opinions.

> any library that treats facts like opinions

The word 'object' has different meanings. One includes arrays and the other does not. They prefer the latter. You prefer the former. I don't think this has much to do with 'facts' and 'opinions', but rather with the practicality of choosing a certain way to speak.

I’d liken it to the word 'sorting'. JavaScript libraries sort in a certain way that is simple to implement. However, this is so different from what we typically mean by 'sorting' that people came up with natural sorting algorithms. Are these people treating facts like opinions on how to sort? I’d rather say, they acknowledge the relevance of a certain way to speak.

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

#78

Post by williamdclt »

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…

> What do you think about empty strings being falsy in most languages including js?

I don’t love it! I think it’s inconsistent with empty arrays being truthy.

In practice, I see a lot more mishandling of empty strings than empty arrays (eg “!myvar” catching null and empty strings when it’s not what was meant) which hints that it’s not the right thing to do: an empty string is a valid string, whether its semantically different from non-empty entirely depends on the context and shouldn’t be baked into the langage.

Generally, I think implicit casts are not a great idea and I’d rather they didn’t exist (one of the few things I think Go got right).

> For example with document.querySelectorAll, which returns an empty array if nothing is found

Yes I think it’s doing the right thing. It’s indeed returning the list of elements, whether there’s 0 elements or more it’s still a valid list. As you say, you don’t usually need to handle it any differently from a non-empty array (just iterate), so I don’t think it should cast to a different value.

However if for example you were passing something like a whitelist as an argument, I’d expect [] to mean “there is a whitelist, allow only these items (ie allow nothing)” and null to mean “no whitelist, everything allowed”. These two things are semantically different, I think it makes sense to cast to different values.

I do see your point and it’s definitely at least partly a matter of taste. Again id rather there was no implicit conversion at all, removing the risk of mishandling altogether!

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

#79

Post by williamdclt »

PUSH_AX wrote: post #51
dcsan wrote: post #31

Earlier quoted context omitted.

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()

Yeah, in practice I would only encounter the case of arrays being objects when doing something highly polymorphic (eg reading some JSON that can be anything), which likely would have test cases for every type anyway.

But when I’m writing a reusable lib and I can’t perfectly abstract a gotcha, I design the API so that the dev _has_ to make an explicit decision rather than defaulting on their behalf (defaults are evil). So, isObjectOrArray and isObjectNonArray: you have to think about which applies. Another example is sorting: does it sort in-place or immutably? Make it explicit in the function name. Does a function expect a sorted array or will it sort itself? Make it explicit in the function name. And maybe provide both variants.

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

#80

Post by the_sleaze_ »

rafram wrote: post #73
insin wrote: post #50

The published version appears to be CommonJS only: $ node index.mjs import { isString } from 'super-utils-plus' ^^^^^^^^ SyntaxError: Named export 'isString' not found. The requested module 'super-utils-plus' is a CommonJS module, which may not support all module.exports as named exports. You might also need to update some of your type checks to handle wrapper objects like new String() - Object.prototype.toString.cal…

> You might also need to update some of your type checks to handle wrapper objects like new String() There’s genuinely never a reason to use new String(). You should treat non-primitive String instances as bugs.

Can you explain a little? I've never heard this.
Post reply on HN