But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to.

Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar.

Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?

To be fair, this is not a problem with the web itself, but with the Node ecosystem.

It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them.

Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users.

The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.

> JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations

It's not unique in this sense, yet others manage to provide a lot more in their stdlib.

It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.

> TypeScripters who need big daddy MS or other monopolist to sort it all out for them

What is this crap statement?

So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies?

Claiming this says a lot more about you than people who use TypeScript.

How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.

For C++ there are Boost, Folly, Absl, several more large libraries with reputable orgs behind them. I'm surprised someone doesn't make a big npm lib like that.

Not hating on the author but I doubt similar compromise would happen to Facebook or Google owned package.

Because you have to figure out what should be in it, and coordinate the distribution. It's not like there's a reference implementation of JavaScript maintained by a well-known team that you consciously install everywhere that you need it.

Because "look at how many open source packages I maintain!"

At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care.

In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.

Because a mini thing can be written in mini time by a mini number of people

The JS ecosystem values quantity over quality, for some bizarre reason.