JS also has a stability issue. The language evolved fast, the tools and the number of tools evolved fast and in different directions. The module system is a mess and trying to make it better caused more mess. There's Node.js, TypeScript and the browser. That's a lot to handle when trying to make something "std".

Meanwhile I have been using Ruby for 15 years and it has evolved in a stable way without breaking everything and without having to rewrite tons of libraries. It's not as powerful in terms of performance and I/O, it's not as far-reaching as JS is because it doesn't support the browser, it doesn't have a typescript equivalent, but it's mature and stable and its power is that it's human-friendly.

This is harder than it sounds. Look at the amount of effort it took to standardise temporal (new time library) and then for all the runtimes to implement it. It’s a lot of work.

And what’s more, people have proposed a standard library through tc39 without success - https://github.com/tc39/proposal-built-in-modules

Of course any large company could create a massive standard library on their own without going through the standards process but it might not be adopted by developers.

If you look at the list of compromised packages, very few of them could reasonably be included in a standard library. It's mostly project-specific stuff like `@asyncapi/specs` or `@zapier/zapier-sdk`. The most popular generic one I see is `get-them-args`, which is a CLI argument parser - which is something Node has in the form of `util.parseArgs` since v16.17.0.

Well they clearly lacked marketing? Pretty sure a red text in npm every time that package was installed that says "hey we have a better way to do this with node alone" would have made a dent in the library usage, but they didn't do anything of the sort.

That is literally how the CycloneDX SBOM packages work, well, after the fact and after the disclosure process.

There's an xckd for that :)

The one with 12 competing standards going to 13 competing standards, or something like that.

Pretty sure Microsoft is exponentially bigger than 99% of the library authors out there, and add to that the giant communication channel that GitHub gives it over developers, so the analogy breaks pretty fast.

Or it's worse, because there's a good bunch of devs that don't trust MS by default?

Even the most hardcore GNU supporters don't think Microsoft would add a supply chain attack to such initiative, or that their software security is worse than the average NPM (popular) package maintainer.

Just the lock in and telemetry are dangerous :)

And they're company policy as opposed to honest mistakes like security vulns.