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

31–40 of 155 posts

Re: The Everything NPM Package

#31

Post by bezier-curve »

o11c wrote: post #29
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?

[flagged]

> There's a reason I still am skeptical of calling client-side devs "actual programmers".

Nothing in your comment actually supports this last jab at web developers. Can you elaborate? I imagine you can't because you're arrogantly posturing.

Re: The Everything NPM Package

#32

Post by spion »

charcircuit wrote: post #4
navtoj wrote: post #2

NPM still hasn't fixed the "*" package version bug on their end. https://www.youtube.com/watch?v=IzqtWTMFv9Y&t=465

It's intentional and is not a bug. "Fixing" it could cause someone's build to break by someone unpublishing a version.

A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.

Re: The Everything NPM Package

#33

Post by spion »

frabjoused wrote: post #27

NPM as a soulless entity is easy to bash, while the creator of the package is a popular tech influencer so naturally has the support of the masses. If you’re going to complain about NPM, describe how you would solve it in their shoes.

Switch to a "softer" interpretation of "*" that rather than blocking unpublishing of every version, allows unpublishing as long as one version is still available.

Re: The Everything NPM Package

#34

Post by remexre »

tentacleuno wrote: post #28
spion wrote: post #21

Earlier quoted context omitted.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

> A well designed JS standard library While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space. The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's t…

There's a difference between features that need to be implemented as part of the engine such as Web Workers and those that can be implemented as a library, such as sorting; the latter can be shared between implementations much easier.

Re: The Everything NPM Package

#35

Post by Bjartr »

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?

IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.

Re: The Everything NPM Package

#36

Post by spion »

tentacleuno wrote: post #28
spion wrote: post #21

Earlier quoted context omitted.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

> A well designed JS standard library While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space. The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's t…

A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine.

Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library (https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very good model that would fit JS fairly well too (with some tweaks and removals)

[1]: https://api.dart.dev/stable/3.2.4/dart-core/dart-core-librar...

[2]: https://api.dart.dev/stable/3.2.4/dart-collection/dart-colle...

[3]: https://api.dart.dev/stable/3.2.4/dart-async/dart-async-libr...

Re: The Everything NPM Package

#37

Post by Uehreka »

charlie0 wrote: post #10
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?

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 datetime picker packages for each framework, and there are debates with good points on all sides about whether the browser-provided pickers are sufficient, or whether this is an area where a level of customization is needed and what that level is keeps changing as people discover new ways of designing date/time pickers and new use cases arise that require different tradeoffs. It’s both really frustrating but also kind of understandable.

Re: The Everything NPM Package

#38

Post by SahAssar »

Bjartr wrote: post #35
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?

IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.

So could you list those problems?

Re: The Everything NPM Package

#39

Post by oskarkk »

tentacleuno wrote: post #28
spion wrote: post #21

Earlier quoted context omitted.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

> A well designed JS standard library While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space. The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's t…

If that standard library would be written in JS, a new browser (or rather a new JS engine being a part of the browser) could just use some existing implementation (a reference implementation maybe?), no need to reinvent the wheel in every part of the browser.
Post reply on HN