Beginning of the Ende (a community Deno fork)
27 points by hongminhee
27 points by hongminhee
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.
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.
https://dbushell.com/2026/10/16/cloudflare-killed-deno/ I suppose
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.
My brother in Christ. YOU reimplemented Node and now you’re bored?
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.
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).
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?
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.
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.
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.