4 ms·

Microsoft should just bite the bullet and make a huge JS standard library and then send GitHub notifications to all the project maintainers who are using anythi

Microsoft should just bite the bullet and make a huge JS standard library and then send GitHub notifications to all the project maintainers who are using anything that could be replaced by something from there suggesting them to do such replacement. This would likely significantly reduce the number of supply chain attacks on the npm ecosystem.

testdelacc1 11mo ago
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 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.
nottorp 11mo ago
There's an xckd for that :) The one with 12 competing standards going to 13 competing standards, or something like that.
- latexr 11mo ago
  https://xkcd.com/927/ https://xkcd.com/927/
- AmbroseBierce 11mo ago
  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.
  - nottorp 11mo ago
    Or it's worse, because there's a good bunch of devs that don't trust MS by default?
    - AmbroseBierce 11mo ago
      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.
      - nottorp 11mo ago
        Just the lock in and telemetry are dangerous :) And they're company policy as opposed to honest mistakes like security vulns.
dominicrose 11mo ago
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.
h4ck_th3_pl4n3t 11mo ago
That is literally how the CycloneDX SBOM packages work, well, after the fact and after the disclosure process.
bakkoting 11mo ago
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.
- AmbroseBierce 11mo ago
  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.

testdelacc1 11mo ago

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 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.

nottorp 11mo ago

There's an xckd for that :) The one with 12 competing standards going to 13 competing standards, or something like that.

latexr 11mo ago
https://xkcd.com/927/ https://xkcd.com/927/
AmbroseBierce 11mo ago
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.
- nottorp 11mo ago
  Or it's worse, because there's a good bunch of devs that don't trust MS by default?
  - AmbroseBierce 11mo ago
    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.
    - nottorp 11mo ago
      Just the lock in and telemetry are dangerous :) And they're company policy as opposed to honest mistakes like security vulns.

dominicrose 11mo ago

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.

h4ck_th3_pl4n3t 11mo ago

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

bakkoting 11mo ago

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.

AmbroseBierce 11mo ago
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.