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

81–88 of 88 posts

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

#81

Post by chrisweekly »

fsloth wrote: post #72
chrisweekly wrote: post #65

Earlier quoted context omitted.

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.

Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities.

What's the alternative? Are you suggesting that backpatching transitive deps dating back over a decade-plus tineframe is a viable maintenance strategy?

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

#82

Post by nothrabannosir »

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

Earlier quoted context omitted.

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.

You’re welcome! ;)

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

#83

Post by cronelius »

ryancnelson wrote: post #41
cronelius wrote: post #38

Earlier quoted context omitted.

lodash is extremely common knowledge in the js/web world. you’re asking a chemist to explain atoms before sharing their big discovery

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.

HN is not a feed of pharmaceutical ads. HN is a place where industry experts in many industries exchange projects and news in _their_ language. HN is going to be a difficult place to live if you are unwilling to google or chatgpt for things you don't understand. Most of us are here explicitly to discover things we've never seen before – there are other places on the web to have everything spelled out

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

#84

Post by fsloth »

chrisweekly wrote: post #81
fsloth wrote: post #72

Earlier quoted context omitted.

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.

Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities. What's the alternative? Are you suggesting that backpatching transitive deps dating back over…

I'm suggesting the "default mode" would be that updating is explicit rather than automatic.

The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.

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

#85

Post by chrisweekly »

fsloth wrote: post #84
chrisweekly wrote: post #81

Earlier quoted context omitted.

Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities. What's the alternative? Are you suggesting that backpatching transitive deps dating back over…

I'm suggesting the "default mode" would be that updating is explicit rather than automatic. The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.

> "I'm suggesting the "default mode" would be that updating is explicit rather than automatic"

This, I agree with. Though for modern codebases, leveraging tools like Dependabot is very helpful. Deliberate upgrades, with automation to make it practical.

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

#86

Post by antifa »

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.

There might be a function called produce in one of your immutable/react lib.

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

#87

Post by moritzwarhier »

williamdclt wrote: post #9
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.

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

Lodash also has "isPlainObject". Not sure if that's as performant as using Array.isArray or even simpler trickery (see below), but it seems that this fixes it.

"isObject" is just not well-defined for other cases that might be interesting, in my opinion. Not just "null" or arrays.

Functions can have properties (although they don't have the object prototype or primitive type).

Class instances behave differently compared to plain objects when used with libraries or other code that inspects the shape or prototype of objects, or wants to serialize them to JSON.

If you deal with unknown foreign values that are expected to be a JSON-serializable value, you could go with something like

  isObject = (o) => !!o && typeof o === "object" && !Array.isArray(o)
But it does not deal with all the non-JSON objects, e.g. Map or other class instances that are not even JSON-serializable by default.

When data comes from parsing unknown JSON, the check above should be enough.

In other cases, the program should already know what is being passed into a function. No matter if through discipline or with the aid of an additional type syntax.

For library code that needs to reflect on unknown data at runtime, I think it's worth looking at Vue2's hilarious solution, probably a very good and performant choice, no matter how icky it might look:

  https://github.com/vuejs/vue/blob/547a64e9b93d24ca5927f653710b5734fa909673/src/util/lang.js#L293
Since the string representations of built-ins have long ago become part of the spec, it seems that there is no real issue with this!
Post reply on HN