The trend of VC-backed tooling ending in abandonment rears its ugly head again. But hey, people gotta eat, right? The community will pick up the slack and steward the projects, right?
Nice, removing Node compatibility is the right thing to do imo. I don’t understand why Ryan thought that was a good idea to implement in Deno, you end up reimplementing Node which he admitted. I suspect he was pressured by their VC to do it for adoption purposes.
It’s a tough call. The Node ecosystem is a major selling point, removing compatibility will make Ende less appealing for many users.
Maybe the ecosystem needs a common API spec, that packages can test against ? But that’s a lot of unrewarding work, that might go wasted not gain traction.
it depends on whether the overall goal is the project is adoption or building a better ecosystem. if breaking node compatibility for principled reason was part of the motivation behind deno then it makes sense to keep building the thing regardless of what adoption numbers it gets (especially now that LLMs can churn out deno-compatible libraries to fill in the gaps).
also while I have no dog in this fight, my personal philosophy for free software projects in general is that if a competitor’s feature set suits your needs better, go ahead and use it. I’ll even add features to my software that make the migration easier if it’s not disruptive.
Maybe the ecosystem needs a common API spec, that packages can test against ? But that’s a lot of unrewarding work, that might go wasted not gain traction.
There’s the WinterTC spec, but it only covers things that are also on the web - fetch, AbortController, setTimeout, that sort of thing. Deno was actually one of the major driving forces behind it. Doesn’t get you node:fs or node:http or similar, though.
The trouble is that node is so popular that a lot of packages are only ever going to target it, spec or no spec. Same problem as IE in the bad old days, and to a lesser extent with Chrome now (although at least there’s consensus that you should test on FF/Safari, even if not everyone does, while there is not at all consensus that you should test your serverside .js app anywhere but node).
Nice, removing Node compatibility is the right thing to do imo. I don’t understand why Ryan thought that was a good idea to implement in Deno, you end up reimplementing Node which he admitted. I suspect he was pressured by their VC to do it for adoption purposes.
score 1 · canonical
I was an employee during the pivot and it had way more to do with bun stealing the limelight than it did anything to do with investors.
score 1 · canonical
It’s a tough call. The Node ecosystem is a major selling point, removing compatibility will make Ende less appealing for many users.
Maybe the ecosystem needs a common API spec, that packages can test against ? But that’s a lot of unrewarding work, that might go wasted not gain traction.
score 1 · canonical
it depends on whether the overall goal is the project is adoption or building a better ecosystem. if breaking node compatibility for principled reason was part of the motivation behind deno then it makes sense to keep building the thing regardless of what adoption numbers it gets (especially now that LLMs can churn out deno-compatible libraries to fill in the gaps).
also while I have no dog in this fight, my personal philosophy for free software projects in general is that if a competitor’s feature set suits your needs better, go ahead and use it. I’ll even add features to my software that make the migration easier if it’s not disruptive.
score 1 · canonical
There’s the WinterTC spec, but it only covers things that are also on the web - fetch, AbortController, setTimeout, that sort of thing. Deno was actually one of the major driving forces behind it. Doesn’t get you
node:fsornode:httpor similar, though.The trouble is that node is so popular that a lot of packages are only ever going to target it, spec or no spec. Same problem as IE in the bad old days, and to a lesser extent with Chrome now (although at least there’s consensus that you should test on FF/Safari, even if not everyone does, while there is not at all consensus that you should test your serverside .js app anywhere but node).
score 1 · canonical