undefined

points

[-]

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|

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.