Is npm Enough? Why Startups Are Coming After This JavaScript Package Registry (redmonk.com) 15
The JavaScript package world is heating up as startups attempt to challenge npm's long-standing dominance. While npm remains the backbone of JavaScript dependency management, Deno's JSR and vlt's vsr have entered the scene with impressive backing and even more impressive leadership -- JSR comes from Node.js creator Ryan Dahl, while npm's own creator Isaac Schlueter is behind vsr. Neither aims to completely replace npm, instead building compatible layers that promise better developer experiences.
Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation.
Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation.
"Problem: There are now 28 competing standards." (Score:2)
Re: (Score:3)
It's both a celebration and a destruction of open source as a concept.
You can publish any sort of tool for others to use in their projects easily, and on the other side you can find a tool for almost anything you need. But the idea of just changing the code you fetch to suit your needs has become an extremely difficult problem to solve. You can't just go edit the code to fix it for your case and push it to your team's repo, and send a patch to the owner if you think it helps.
No. Now you gotta go up to th
A question (Score:3)
How on earth did anyone ever write code before the advent of these always connected library collections?
Re: (Score:1)
You downloaded the libraries manually. As the repositories became more popular, and there was more cross-library code reuse, it required downloading more and more libraries individually. So the package manager was born.
Re: (Score:2)
/dev/random
the predecessor to CoPilot
Re: (Score:2)
Back then, you had the MST3K fan motto: Keep circulating the tapes. Tapes with all kinds of useful code would be passed along and copied. That's what User Groups were for.
Re: (Score:2)
Punchcards, of course.
waste (Score:2)
Re: (Score:3)
Why does anybody use such a broken ecosystem when alternatives exist?
Is it just because nobody wants to write their own libraries anymore?
Re: waste (Score:2)
Anymore? Nobody ever wanted to, they had to.
Every language... (Score:3)
Has the package manager it deserves. It is a reflection of the language's community.
NPM is:
More JS package managers won't fix anything. All the problems stem from what the JS community considers to be a package, and that in JS world DRY actually means desiccated.
No other language's community would sincerely entertain the notion of an is-even package.
XKCD as predictor of real life (Score:1)
NPM needs to improve (Score:2)
The NPM site needs to improve and do a bit in terms of quality control. My items:
- Preventing publishing packages with no linked website or README.md
- Prevent duplicate packages which are just referring to the same GitHub repo (currently they don't seem to care)
Probably... (Score:2)