It makes 100% sense for Deno to do this from a business and marketshare standpoint: they need those modules in order for people to make the kind of projects they're making with Node. But I was really hoping that Deno would be a reboot: flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt. In some ways "1.3M new modules" is more scary than impressive.
But alas, here we are. We've got the JS ecosystem we deserve.
> flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt
This kind of view is very prevalent in the web community, and in my opinion it's often the failing of the ecosystem. Good engineering takes time, there's almost no project out there that nailed everything on day one. It is through iteration and progressive improvement we achieve big things. Anyone with a crash course in programming can publish a library in a week. But it takes proficiency and hard work to maintain an interface over years or even decades. There is also no such thing as a perfect solution. Every solution makes tradeoffs and being able to adapt to tradeoffs relevant to your problem is a huge aspect of engineering.
Deno going the scorched earth way would mean pulling back the ecosystem by at least 10 years. There is no guarantee they will get things "perfect" this time around. In all likelihood, they eventually would've come up against the same set of constraints the original ecosystem did, make similar tradeoffs and there would be a conversation 10 years from now about needing a reboot.
The right way to do is to embrace legacy and build solid tooling where the legacy gives you rough edges. Another big aspect of engineering, in my opinion, is not being fanatical about aesthetics. Function over form, every time. I'm glad Deno is taking this route, I was previously critical of their choice to fork core packages like dotenv, semver, base64 etc, but hopefully this will move the community towards consolidation rather fragmentation.
I agree - Deno did this right. They built the runtime ignoring NPM existed so it wouldn't compromise design principles, but left the window back into that ecosystem open so they could reap the benefits of "backward" compatibility.
I do think if Node has a successor, it won't be a future version of Node - it will be Deno. There is too much that Deno does better to ignore once all the compatibility is there to migrate.
TLDR: Starting from scratch is rarely a good idea. (just read it though, it's not that long).
The fact is that there are lots of good npm packages that have had tons of time and effort put into them, and years of running in production to prove their worth. Yeah there are some dumb packages and micropackages seem like a mistake, but there's no reason to throw it all out.
If the new js module ecosystem really is better, then js developers would publish new modules there instead of npm, and eventually legacy modules on npm would be migrated over. I don't think that is the issue. You don't have to use NPM to use deno, it's just an option. But yes, NPM is scary.
Yes but people usually follow the path of least resistance. If modules are on NPM they'll stay on NPM if there's little incentive to rewrite as ESM isomorphic modules and publish for Deno.
1. The legacy language baggage of different syntaxes, bad Node APIs, non-standard import styles, etc
2. The existing ecosystem of actual packages and their capabilities
It's a good thing that Deno isn't a reboot of #2. Despite the recurring narrative on HN, the scale of the NPM ecosystem is a good thing. It's one of JavaScript's greatest strengths. I don't understand all the people complaining that they're given too many powerful and free packages to choose from. Whenever I've brought Deno up to people at work or otherwise, their major source of hesitancy for using it on real projects is (rightly) that it's lacking Node's vibrant package ecosystem: "Does it have a mature auth library? What about an AWS SDK? GraphQL server? Client? Redis library? What if we need something later that we don't know we need yet?"
As for #1- Deno is still a reboot, just a softer one. It still gives people lots of reasons to write new packages in the well-formed, web-standard-based way that Deno directly supports. NPM compatibility is a bridge to get us there gradually (because that ecosystem is so valuable, and can't be rebuilt overnight).
It was always a bold move to try and go scorched-earth, and especially with the new pressures from Bun, I think it was the right call to make this exact level of compromise.
Well, Deno by itself won't solve the supply chain attack problem. Crowd review might[0]. It's cute that npm/yarn/github/dependabot/renovate all warn if there's a security issue, but at that point it's a bit too late. (Better than nothing, definitely, a step in the right direction, but not a solution.)
Clean reboots are always hard, usually don't work out. Just look at the Py2-Py3 transition. Also there's a Perl6 story somewhere here. (Relevant xckd[1], relevant c2 entry[2] )
That's exactly what they tried, by settting up a Deno-only registry.
But there is just way too much work and momentum happening in the NPM ecosystem. Many library maintainers wouldn't want to bother maintaining separate packages for a barely-used ecosystem, and users will be less likely to switch because they can't use the existing (huge!) ecosystem.
It's the same language after all, "just" a different standard library (which is very impactful for lot's of server-side code) and packaging/distribution mechanisms.
It makes 100% sense for Deno to do this from a business and marketshare standpoint: they need those modules in order for people to make the kind of projects they're making with Node. But I was really hoping that Deno would be a reboot: flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt. In some ways "1.3M new modules" is more scary than impressive.
But alas, here we are. We've got the JS ecosystem we deserve.