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

The Everything NPM Package

socket.dev

Post reply on HN
Print view View original

71–80 of 155 posts

Re: The Everything NPM Package

#71

Post by throwitaway1123 »

o11c wrote: post #67
throwitaway1123 wrote: post #53

Earlier quoted context omitted.

This is a vague statement filled with poetic language that conveys very little useful information. I can't imagine trying to parse this as a non-native English speaker and extract any sort of meaningful information from this comment.

Okay, by example then: * if you just bash on the keyboard randomly until you get a result, or just copy-paste from StackOverflow, or just let an LLVM spew something, that's not programming - there's no choice. * if you do deliberately choose something, but your choice fails to produce a meaningful result, that's not programming - there's no order.

Ok...and how exactly does this invalidate client side programming?

> * if you just bash on the keyboard randomly until you get a result, or just copy-paste from StackOverflow, or just let an LLVM spew something, that's not programming - there's no choice.

To add a more substantive example to the conversation: do you really think the developer of Photopea built an entire Photoshop clone in the browser by mashing keys on his keyboard randomly? You think there was no choice in the development of a project like that?

> * if you do deliberately choose something, but your choice fails to produce a meaningful result, that's not programming - there's no order.

Do you think the client side developers behind something like Google Docs have failed to "produce a meaningful result"?

You've come up with an interesting set of criteria, but you have nothing to apply it to. That's why your original comment was flagged, and referred to as posturing.

Re: The Everything NPM Package

#72

Post by nosefurhairdo »

scubbo wrote: post #50
charcircuit wrote: post #24

Earlier quoted context omitted.

The same can be said about not pinning to a specific version as even some patch releases can break things or change performance characteristics.

This, to me, is still one of the most astonishing things about the JavaScript ecosystem that everyone just accepts.

Not a big deal, just specify exact dependency versions. Curious how you think other package managers handle this better than npm.

Re: The Everything NPM Package

#73

Post by jonorsi »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to under /lib or /third_party, and be much more suspicious of new package dependencies.

Basically, you would need to start accepting that you are responsible for any dependencies you choose to include. Any upstream changes you would need to evaluate and bring in or patch yourself.

Definitely an impossible task given how broad and deep modern package dependencies are, but at least you’d start feeling the insanity of having all if them in the first place :P.

Re: The Everything NPM Package

#74

Post by Stevvo »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

The one thing clear in JavaScript is that if some developers think there is a better way, they will develop it and use it. That hasn't happened with NPM because its about as useful as it conceivably could be. The criticisms really amount to nothing, and tend to come from developers who don't even write JavaScript.

Re: The Everything NPM Package

#75

Post by BeefWellington »

cybrox wrote: post #61
baz00 wrote: post #54

Earlier quoted context omitted.

Personally I would like it and the ecosystem to just cease to exist overnight. Nothing on earth has caused so much pain, misery, suffering and agony, apart from possibly PHP. Our devops guys scream from the seething pain whenever the have to debug some pile of shit that decides it won't build unless all the runes are aligned precisely and all the RAM in the universe is available on the build runners. And pushing this…

I mean... just don't install everything then? Over-reliance on third party dependencies is a choice. One could argue that it's unreasonable not to do it if you want to stay competitive but good luck changing human nature then. If there are shortcuts, they will be taken.

While this is true, when the shipped standard library by NodeJS lacks so many VERY BASIC features that every other language has, OF COURSE developers choosing/being instructed to use JS so that frontend and backend languages are synced are going to reach for packages to solve whatever functionality should already exist in code like: "Jim".leftPad(4)

Re: The Everything NPM Package

#76

Post by cxr »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

I know it's five hours later and this question has already spawned dozens of responses, but it's worth thinking and speaking clearly if we're trying to arrive at a solution for something. We can start by saying exactly what we're talking about—how do you make what different? Because you mention npm "and their policies" but then switch gears and talk about "is-odd", which is not a policy issue. It's rather something else entirely.

If you want answers, state clearly what _specific_ problem you're trying to solve. Whatever the solution to it might be, vague and fuzzy questions—while magnets for chatter since they can stand in for whatever someone wants to read out of them—are not the way to get there.

(You could say that this is needlessly tedious because everyone already knows what we're talking about, but that this isn't true is exactly my position. It's certain that something like half the people reading, thinking, and writing are have in mind one thing, while the other half are thinking of another—and the third half are thinking about something different from either of those. We're also programmers, so dealing with tedium and the constraints of having to be explicit should be second nature.)

Re: The Everything NPM Package

#77

Post by richbell »

strken wrote: post #62
richbell wrote: post #49

Earlier quoted context omitted.

Namespaces, for one.

Namespaces in Maven seem like they're clunky. The pseudo-DNS thing where the first section is an actual domain but the second is whatever you want is quite janky, as is not matching the namespace to the package. Plus domains are transferable themselves and it seems like a bad idea to use them as identifiers. Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly d…

> Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did.

I'm not saying that they should have blindly copied Java, but they should have had something.

Re: The Everything NPM Package

#78

Post by mkoryak »

Affric wrote: post #42
nosefurhairdo wrote: post #18

Earlier quoted context omitted.

Perhaps NPM should apologize for shifting blame and failing to address the root cause. The wildcard "any version of dependency" preventing unpublish is clearly flawed. The "everything" package folks had no malicious intentions, and nobody would benefit from a long-winded, ashamed apology. If not for NPM's flawed unpublish policy the everything team would've unpublished to resolve the issue.

I agree to a large extent but I am not sure even rereading my comment that I can take that that’s what I am advocating for. I just think it would have been good to give the “I was hoping to investigate X, I did not expect Y, I can see now that it was irresponsible to do X.” I don’t think that’s particularly long winded.

I don't think he was trying to investigate anything. He was just trolling, but he didn't intend to troll _that hard_.

Re: The Everything NPM Package

#79

Post by com2kid »

Uehreka wrote: post #37
charlie0 wrote: post #10

Earlier quoted context omitted.

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. I just need 1 really good sorting library. With it, we can move to less overall dependencies on random packages.

> I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. This feels like a bit of a strawman, since sorting is already in the standard library and there aren’t in fact popular sorting packages for each framework (that would in fact be ridiculous). If you want to start a real debate though, bring up date/time pickers. There are multiple date picker, time picker and date…

> There are multiple date picker, time picker and datetime picker packages for each framework, and there are debates with good points on all sides about whether the browser-provided pickers are sufficient,

Safari (iOS and MacOS) still doesn't have full support for the date time picker, which is why there are so many alternatives.

Re: The Everything NPM Package

#80

Post by willy_k »

hnlmorg wrote: post #66
strken wrote: post #60

Earlier quoted context omitted.

There are two massive reasons why js got here, with a million packages for tiny things and a culture of using them: browser cross-compatibility requiring complicated workarounds for easy-seeming tasks, and the introduction of promises + async/await to node.js after the standard library already used callbacks. When you combine those together you end up with a situation where "normal" js code not from a library can't b…

Modern JavaScript reminds me a lot of BASIC, Pascal and other 70s and 80s languages. Even C pre-ANSI. We’ve been blessed in recent years that either languages are fully open source and come with a reference implementation, or a standards body governs the implementation detail. Sometimes even both. Whereas JavaScript is really more a group of languages, each with their own implementation quirks. ECMA was intended to b…

> Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.

I mean, it’s not necessarily “in the JS world”, but WASM is basically that.

Post reply on HN