I really don't like the entitled tone of that post. Yes, it sucks that it will be officially EOL soon-ish, but blaming the people who move on is not the way to go. But I hope it works out.
Or maybe I've just lost all my fucks to give years? ago when they added node compat and pivoted away from the thing I found relatively good. I'm not a heavy user and as long as I can host my "dozens of requests per week" projects on deno.land I will stay there, but maybe it would be easier for me to just migrate those off (again).
Eh, it's hard for me to call it entitled when he's picking up development himself, not just complaining about it. I'm glad someone's keeping Deno alive, even though adoption was always a problem and now the one-two punch of a fork and the removal of Node compat means that it will be even harder to find compatible libraries for Ende.
Ironically I was recently considering moving a few of my in-progress projects from Bun to Deno because of Bun's instability (and acquisition by Anthropic), but now I suppose I'll just move them to Node. Node has become the Borg at this point: it assimilates its competitors' strengths and absorbs them. (Remember io.js?)
I would agree with you if the post was "I did a thing and have picked up maintenance" and not "I will do that" (hopefully/maybe/soon).
Maybe entitled is slightly the wrong word, but it's just as it goes. It's FLOSS (fully, afaik) and people work on it as long as they want. If they stop because they lost interest or got bought out.. doesn't really matter to me.
You may be aware, but I know I had to backtrack to understand the wording in the post, but the term "EOL" as it was used in the post itself is about author's upcoming project which I think will be a code forge or something. I tried to find out more and gave all 10% effort for it and I still don't know what it may be.
It's not that EOL in your comment is a wrong term, but I wonder if the word appeared in your mind, because you saw it in the post, even if it was about something else.
I had a feeling someone was going to do this. Deno has a lot of great ideas and I honestly thought it would have been more popular with developers compared to the other runtimes but I was wrong.
Even at work we've moved to running applications on Bun because of the Node.js compatibility and not having to set up a build step for typescript.
I hope Ende has a good run and I wish it all the luck. I know I'll probably use it for my local and personal projects (as I did with Deno).
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.
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).
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.
This is a great demonstration of the Free Software movement's power. When sellout occurs, rather than the software being enshittified, if it still is providing value then it can be forked and maintained by the community of people who use it.
In this case, however, I don't really see the point. Admittedly, I am biased because I've always thought Node.js was a great project and thought that the ways Deno set itself apart from Node were actually bad design decisions (such as importing from URLs).
I mean, come on, how much time are we talking about realistically to "learn Node.js again"? 10 minutes?
I'm happy to see this happen even though I never used Deno as it was VC-backed. Hopefully it will continue to be a source of inspiration for other JS runtimes and I might even use it if it continues to be maintained.
edit: Per-module permissions and sandboxes for untrusted code as they describe their goals would be a major reason to use it, given the security downsides of the npm ecosystem
As much as I enjoyed using Deno I don’t get the obsession with the actual runtime. If you run your own server(s) just lock the binary to whatever version works for you and keep running that forever. The devs that invested fully using Deploy are the real losers here.
abbe | 5 hours ago
How is it an anagram ?
hjvt | 2 hours ago
If you can't count the Rs in "strawberry" then it's close enough?
lilac | 2 hours ago
especially frustrating because oden is right there.
wink | 7 hours ago
I really don't like the entitled tone of that post. Yes, it sucks that it will be officially EOL soon-ish, but blaming the people who move on is not the way to go. But I hope it works out.
Or maybe I've just lost all my fucks to give years? ago when they added node compat and pivoted away from the thing I found relatively good. I'm not a heavy user and as long as I can host my "dozens of requests per week" projects on deno.land I will stay there, but maybe it would be easier for me to just migrate those off (again).
ar-nelson | 5 hours ago
Eh, it's hard for me to call it entitled when he's picking up development himself, not just complaining about it. I'm glad someone's keeping Deno alive, even though adoption was always a problem and now the one-two punch of a fork and the removal of Node compat means that it will be even harder to find compatible libraries for Ende.
Ironically I was recently considering moving a few of my in-progress projects from Bun to Deno because of Bun's instability (and acquisition by Anthropic), but now I suppose I'll just move them to Node. Node has become the Borg at this point: it assimilates its competitors' strengths and absorbs them. (Remember io.js?)
wink | 5 hours ago
I would agree with you if the post was "I did a thing and have picked up maintenance" and not "I will do that" (hopefully/maybe/soon).
Maybe entitled is slightly the wrong word, but it's just as it goes. It's FLOSS (fully, afaik) and people work on it as long as they want. If they stop because they lost interest or got bought out.. doesn't really matter to me.
kwas | 3 hours ago
https://dbushell.com/2026/10/16/cloudflare-killed-deno/ I suppose
taskyliz | 5 hours ago
Pretty sure they're winding down Deno Deploy in 6 months so unfortunately you will have to migrate.
wink | 4 hours ago
"as long as possible" would probably have been the better wording :P
hawski | 3 hours ago
You may be aware, but I know I had to backtrack to understand the wording in the post, but the term "EOL" as it was used in the post itself is about author's upcoming project which I think will be a code forge or something. I tried to find out more and gave all 10% effort for it and I still don't know what it may be.
It's not that EOL in your comment is a wrong term, but I wonder if the word appeared in your mind, because you saw it in the post, even if it was about something else.
At least that short-circuited in my head.
refi64 | 5 hours ago
I'm not sure if this is that he's bored, rather than reaching the "acceptance" stage on what he perceives to be the general perspective.
dsh | 9 hours ago
I had a feeling someone was going to do this. Deno has a lot of great ideas and I honestly thought it would have been more popular with developers compared to the other runtimes but I was wrong.
Even at work we've moved to running applications on Bun because of the Node.js compatibility and not having to set up a build step for typescript.
I hope Ende has a good run and I wish it all the luck. I know I'll probably use it for my local and personal projects (as I did with Deno).
skykanin | 7 hours ago
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.
moltonel | 6 hours ago
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.
bakkot | 3 hours ago
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).
zem | 39 minutes ago
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.
lilac | 2 hours ago
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.
andrewrk | 2 hours ago
This is a great demonstration of the Free Software movement's power. When sellout occurs, rather than the software being enshittified, if it still is providing value then it can be forked and maintained by the community of people who use it.
In this case, however, I don't really see the point. Admittedly, I am biased because I've always thought Node.js was a great project and thought that the ways Deno set itself apart from Node were actually bad design decisions (such as importing from URLs).
I mean, come on, how much time are we talking about realistically to "learn Node.js again"? 10 minutes?
chenghiz | 7 hours ago
I'm happy to see this happen even though I never used Deno as it was VC-backed. Hopefully it will continue to be a source of inspiration for other JS runtimes and I might even use it if it continues to be maintained.
edit: Per-module permissions and sandboxes for untrusted code as they describe their goals would be a major reason to use it, given the security downsides of the npm ecosystem
ale | 3 hours ago
As much as I enjoyed using Deno I don’t get the obsession with the actual runtime. If you run your own server(s) just lock the binary to whatever version works for you and keep running that forever. The devs that invested fully using Deploy are the real losers here.