undefined

points

[-]

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.

This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.

A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.

That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.

With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.

by homebrewer3 hours ago|

parent|

[-]

This has been improving recently; one large project built on several heavy libraries that I've been supporting since 2018 currently installs ~180 dependencies without loss of functionality compared to how it worked, and what it depended on, back in 2018.

IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself:

- 5 deps: https://www.npmjs.com/package/react/v/15.6.2

- 0 deps: https://www.npmjs.com/package/react/v/19.2.6

Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.

by sysguest1 hours ago|

parent|

[-]

hmm maybe time to get into deno?

I mean, the current "allow ANY filesys operation" can't cope with modern supply-chain attacks...

with deno, you can specify folders/files that the execuble/library CAN touch (or CANNOT)

by oblio2 hours ago|

parent|

prev|

[-]

> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.

Which is another part of this entire insanity:

Browsers are already <<huge>>. They're also built by <<huge>> companies companies that collect <<tons>> of analytics.

You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.

It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...

by johannes12343211 hours ago|

parent|

[-]

That was circumvented once by CDNs hosting common libraries so that those would stay in browser cache, browser vendors then "broke" that by caching per origin. (So that an evil site can't detect whether a user had been on some target site before by testing whether assets are fetched from cache)

Issue probably is that the standards process is slow (unless it is a feature Google "needs") and full of bike shedding (which features and how exactly they'd look) and adaption of features by developers is slow.

JavaScript meanwhile should be stable enough as an environment to allow a broader standard library.

Luckily it is slowly getting better (see Temporal as new date library, replacing moment.js usage in many places)

by skydhash2 hours ago|

parent|

prev|

[-]

The web api is actually extensive. I can understand complaints about it being not exactly approachable, and some wanting a cleaner abstraction, but there’s no way that it is small. Most issues is about people wanting to download a small library than just vendoring the small snippet of code.

The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.

by homebrewer3 hours ago|

prev|

[-]

How large a project do you typically use dotnet for?

IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.

by orphea2 hours ago|

parent|

[-]

I don't think going commercial has been that impactful. It sucks, it betrays the spirit of open source but whatever. A few examples:

- FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here.

- Moq lost trust - we have NSubstitute

- AutoMapper and MediatR have been widely misused anyway

- Maybe MassTransit is a real bummer?

by Pay082 hours ago|

parent|

[-]

Switching to the forks/alternatives is still time and effort, often a lot of it.

by bob10292 hours ago|

parent|

prev|

[-]

> How large a project do you typically use dotnet for?

The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.