> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.
If it was truly “so many companies” then they wouldn’t be in this situation… reading between the lines here it’s clear Deno was not a successful project.
Whoever did it, decision maker was reckless and should his job should be reassessed. This is not surprise, similar will happen to Bun as well, just matter of time.
Node was once the shiny new thing, so that argument is irrelevant. Deno got a lot of traction by promising to fix Node’s issues, some people trusted that promise, and Deno just didn’t deliver.
Deno always felt like a "people pot", the kind of company whose sole (but unstated) purpose is to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company who can actually utilize them. The actual product was secondary at best.
Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.
At least open source gives them an opportunity for the community to find a way to support it going forward. But I suppose that's just table stakes these days.
I was really surprised that cloudflare was acquiring deno to be honest, I have written about this here before, Deno was always sort of dead to me due to how little they cared for compat of all kinds (nodejs, CJS, backwards). It was refreshing to see bun care a lot about it (well, now its on a different path in other ways).
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
>So many companies went all-in on Deno in recent years.
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
I mean, if you have any test suite worth a damn, then this should only cost a few dollars in tokens for the average team and be nothing more than a minor inconvenience.
> So many companies went all-in on Deno in recent years.
I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.
Well, the license Deno is distributed under explicitly warns you (sorry for all caps):
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.
As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad". They might reevaluate that in light of things being generally fine and losing their precious handcoded runtime choice.
‘Acquires’ is an interesting word, given they’re hiring people and sunsetting the product. They didn’t buy Deno, they hired the team that built it and that forces them to abandon the project.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
I think it’s covered appropriately for the audiences. The two posts are for different audiences and purposes. The Deno post by Ryan is for the Deno audience, which is mention at the top of his writing on the Cloudflare post that is for a broader audience of what this means for the Cloudflare audience:
“For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.”
FWIW both Ryan and Kenton are very transparent in person, in public, and online over their professional careers. They will and do openly change their minds based on new information and opportunities as time goes along. Both are now founders of open source projects acquired by Cloudflare for the technical architecture talents seeing a future that they would like to build.
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land.
I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
> since it push on semantics that can only be run on Cloudflare infrastructure
No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).
Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.
that's an interesting reflection on the nature of open source - in theory the source is there and "the community" could conceivably continue development. especially in the case of something like deno where the people most motivated to keep it alive are already programmers. but the reality is that however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.
hopefully that single entity can be a consortium of companies invested in using the runtime, sort of like opentofu recently.
I'd say it's durable object specific. Both team deno and cloudflare (and many others) have been won over by the paradigm. Cloudflare is just the primary implementers of it as a strong example of an actor-based programming model at infra layer, but others have been trying to push it (Rivet, and TerseAI's durable actors, celld)
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.
Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.
Phrased as it being merged into the existing, but I can't help but fret a bit. Is cloudflare willing to let their own core compute product be something available to the world? Absolutely sick wins if so. But I worry celld pretty reasonably seen as a threat.
Funny that with Bun being acquired by Anthropic, if this big bet on AI doesn't work out we'll end up right back where we started; Node. Obviously Deno will still be OSS, Bun would likely end up that way too, but you get the idea
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?
US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.
But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.
(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)
(There might be something the state of California could do, but I don't know how much they want to get involved.)
Do you think Deno was real competition for Cloudflare, and now that they've merged we don't have alternative options for goods/services that are mostly essential?
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.
I'm so bummed about this. Deno is by far my favourite JS runtime. I could sense this coming for a while now, but I was hopeful and just waiting to see what happened. Here we are. I'm glad I don't need to get off the runtime immediately. Sad we won't see any innovation like we did in the last 8 years or so.
I hope workerd at least adopts Deno's security mechanisms so it functions as a better sandbox.
One of my favourite projects of 2026 was a configurable LLM harness built around using deno as the runtime. The idea is that the configuration builds a state machine-driven program which is bundled into a binary that can only provide access to the I/O your code explicitly needs. I used it primarily to build interactive programs for colleagues which allow some LLM magic to occur without needing to worry about what they would do with Claude Desktop handling the same data or accessing the same machines and so on. It also allowed for testing local LLMs in deterministic patterns. How do they reason about what to do next when they can evaluate the possible states they can enter, based on the current context? It was really fun. Now I don't really know how I'd rebuild it, knowing I wouldn't use Deno. Maybe that's worth learning anyway.
I loved early Deno and am sad to see it die. I invested heavily in the Deno ecosystem because of Ry’s initial vision for it.
But I stopped because I saw this coming the moment they changed course and started putting npm compatibility as a priority. Deno’s surface area went from beautifully simple to very bloated. I think they felt the pressure of VC funding and just gave up on rebuilding Node from first principles.
The silver lining is that early Deno was so good that Node copied some of its features. So at least we have a better Node now.
Bun's adoption rate (because of its NPM compatibility) was the forcing function; not VC funding. Deno could pursue a slow-and-steady better-will-win approach vs. Node until another runtime competitor appeared with a more seamless node integration. In fact, the VC funding is what made the slow-but-steady strategy possible in the first place.
Strong disagree. Deno could have been a cheaply run open source project with corporate sponsors and could have pursued the slow and steady approach. There's no reason to feel pressure from competitors unless you want to if you're forging a genuinely new path. "Clean break from Node" was the differentiator. Once they abandoned that the reason for using it went away.
The moment they took on VC funding they had to care about competitors and also had to move away from the framework to things like Deno Deploy in pursuit of money.
I'm trying to understand this. Cloudflare wants the people to work on different priorities or cloudflare wants deno to die?
In the case of the latter, I'm wondering why. Most of cloudflares architecture like workers support js runtimes so wouldnt investment into deno be more strategic than other priorities
I'm more thinking of "Deno (the company) lost interest/faith in Deno (the runtime), so they were looking for an out". They like working with runtimes, so Cloudflare is probably a good choice.
I guess this is why so much core staff left suddenly some months ago.
It’s likely that this could be true but they simply have something else they want the acquihired to work on and feel Deno would be a distraction. At least they’re being honest with it instead of letting development stall and all the ill will that comes with the usual slow death by acquisition
RIP, my favorite JavaScript runtime, and thank you. You were too secure for this world.
What kind of business move is this for Cloudflare? celld is a more complete Cloudflare-at-home runtime than current workerd. What does Cloudflare stand to gain from commodizing Workers?
I'll say that although I'm not really a Cloudflare Workers user, I've been eyeing workerd and celld with interest. The idea of a complete backend in a box appeals to me (see also: PocketBase, Algernon). At the same time, the acquisition means that another company won't acquire Deno for celld.
From the Cloudflare blog post, this quote from Kenton Varda (head of Workers):
> "Lock-in" actually hurts us — that's why we went open source
If there were truly no escape hatch from Workers, then some of our largest customers would never have signed on with us in the first place.
> [...]
> Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd. I'm incredibly excited for this work — I will personally be using it to host an instance of Cloudflare OS in my home.
Love the transition from being secure on my machine to being secure on somebody else's machine. This offers additional security by making it impossible for me to move the code anywhere else. Which solves the common security problem of me moving my business anywhere else.
> there is no a single Durable Objects alternative at the moment
If you live in Elixir land, there's this repo from the Phoenix team, which is quite good. It has pluggable storage, and EKV (https://github.com/chrismccord/ekv) is supported as "batteries include" type storage adapter.
A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.
I've been following celld since it was announced. Bootstrapping both durability and coordination off object storage simplifies so many things for self-hosting. (Yes, ironic that self-hosting has a cloud dependency, but in this case I think justified because S3 has become a widely supported protocol that you can run yourself too).
Will be curious to see the details on exactly how that model makes it into workerd.
The plan is to bring the celld model to workerd: run a fleet of workerd instances that use a bucket for coordination and storage. Building on workerd, instead of a separate runtime means our effort isn't split and that APIs are exactly the same in both CF and self-hosted. And of course the deno team will help improve the worker runtime itself.
>A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.
I think people are focusing on it because if you've built your business on Deno, then the "Deno will have no support in 13 months time" is a bit of an existential risk, and will be a huge time-sink for your team. So it's far more interesting to most of the people reading this page on HN, because HN is full of people who are first-adopters.
I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively.
Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now.
That's a pretty uncharitable take. It literally only exists because of him, he pushed hard for it for years, and now he's decided not to anymore it leaves a bitter taste? What do you want him to do?
What's with the downvotes? Do people doubt that this type of work is something AI is particularly good at? Or is it just resentment against the resulting fact that making the right architectural decisions isn't as important as it was?
I have felt very misled with the communications around this like this X post. They say Deno + Cloudflare. But at the bottom of the post it's clear that Deno is RIP.
Deno's ability to import directly from a package registry or even git repo in a standalone TS script without requiring a package.json or similar 'meta-data' file was actually really nice for shell scripting stuff. AFAIK node.js still can't do anything similar?
I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.
of course i’m only talking about deno, the technology not deno, the cloud service.
> I’m happy if this means Deno is able to get a second impulse
Bad news, sorry, the article says:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Sounds like Celld will live on within workerd, Deno is over.
> I’m happy if this means Deno is able to get a second impulse.
From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
The fact that Deno development is being suspended doesn't mean the community can't step in. The Deno runtime is licensed under MIT. Such forks might be impulse to grow even further.
Damn. Deno is a super old project, in 2018 the Nodejs creator did the talk "things I hate about NodeJS" and introduced Deno. It's 8 years ago now, and clearly even though the project was known by most Node users, it didn't gain any traction at all. I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ? Anyways Node will keep evolving and implement new features, new standards, optimization. I think it's super risky to move to an alternative. In the age of the LLMs, if you wanna get out of Node, you better translate all to native Go or Rust.
"old" is relative term. Given @TheRogue's account is 4 years old, maybe new to field. If so, it feels "old".
I understand your sentiment of justifying not being "old". but you gotta bring up "legacy code".
"Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
So either @TheGuardian is discussing about the age of software relative to his/her perspective or confused "legacy code" without understanding deno code base.
It may not be old, but it sure hasn’t caught on much after 8 years. I did remember a lot of posts about migrating cloud functions/lambdas to deno initially, but not much since.
I’m taking the stance that no news is bad news here. If it was good, people would be doing Resume Driven Dev with deno and we would be buried in those articles. Alas.
It's not that old, but it's old enough that it should have gained a bit of traction, it should have been mentioned in more discussions etc. And ultimately adopted more. It's purely a gut feeling though because I didn't run any numbers
The main thing was the permissions model and the other runtimes in fact did not learn from it. And there were real big consequences to the node's insane package management model recently.
You can also see that JS developers don't really care about any of this stuff by reading the comments here, people don't even mention this and mention native typescript support like it is such a important thing to have for a significantly large/long-running project.
To me Deno died the day it decided to not support npm packages and died again when it started supporting it.
Ironically the reason why I hated it when it was introduced was the reason why they added support for npm (i.e. absolute URLs don't support semver and therefore you will load multiple versions)
In what way does supporting npm packages compromise Deno's design? I don't know a lot about Deno but thought it was more about rewriting in Rust, more batteries included like native TS support, and more secure defaults.
Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.
I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless
Cloudflare could make the biggest impact by doing something similar to AWS DSQL. There are very few options in the multi-region replicated space, and it ties in nicely with their edge workers.
I'm very surprised they are not running with the runtime. That seemed like Deno's secret sauce? The rest of it is very aligned with Cloudflare already, deploy, kv, workers, etc seems like the lower hanging fruit.
It's almost certainly not worth it. Having less software that you can keep more reliable is almost always worth it over having more software just because it's 10% faster or whatever. This isn't always true but it's mostly true.
Very unfortunate. I’ve been using Deno for years and recently embedding the runtime into applications/platforms for agents. I’ll continue to use it and hope a community springs up.
All of this just re-informed my believe to stay with true and tested systems that have survived decades. C if I fell confident and Common Lisp otherwise. Both standardized, have been around for ages, and they don’t disappoint.
I feel bad for anyone that now relies on Deno. And as good as Cloudflare might be for some things, I also feel bad for anyone relying on them.
It looks like, after Oracle kept on pushing out the deadline for a certain step in the suit process, the parties are in settlement negotiations now [0]; the motion was granted [1], so we might see more info after October 28th.
I'm very sad Deno is going away, even though I've never used it nor did I plan to use it.
It is a bit hypocritical in a sense. Similar to how I was sad that a local restaurant recently closed down. In the past two years I went there maybe three times total. But I just liked having it there as an option.
Deno had a ton of good ideas but I just never felt confident that it would have the lasting power. Some of the early decisions, like their initial refusal to fully support package.json and the npm eco-system, made me unsure of their suitability as the basis for a business.
But I always wanted them to succeed. In the same way I always wanted Heroku to succeed even though I never used their service.
More options are better. But I guess "use it or lose it" applies. Did I dodge a bullet or contribute to the downfall?
I had to evaluate Deno vs. Bun vs. Node for a project two years ago, and chose Node. I think Deno has good ideas but often times these projects cannot reach escape velocity, especially when they're constrained by VC motives.
It's really interesting folks at CF and Deno making this decision while unikernel slowly integrate into mainstream cloud computing as Prisma and Netlify adopting Unikraft. With AI is getting better each day there will comes a day when people be like "why we still running javascript in server?"
Does anyone know how many paying Deploy customers there were? The post only offers migration help to paying customers and gives them six months, which makes me think the number is small enough to hand-hold. Millions of runtime downloads and a few hundred accounts on a paid plan can both be true, and only the second one pays for a team.
This is a real bummer. Work never adopted Deno but I love their model, security posture, and the standard library. I've been less interested in typescript recently, but it has turned into the default for frontend.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
This might not be seen in much favourable light by many but IMO Cloudflare has the most elegant serveless PaaS as I have seen to date.
The design and architecture is extremely minimal to the point that all of it can be explained on a single A4 page with a 14pt font including D1 + Durable objects. And I hope that it stays that way.
It has all the primitives that you can wish for to build a software system on top of it be it queues, long running jobs, workflows, pipelines, email handlers, cron jobs and even built in AI models ready for you to be invoked.
ATM - it is extremely cheap, reliable, simpler and more capable than anything out there. Deno itself had very little scope anyway because almost no developer tooling is sellable in this environment even more so post AI. Therefore, it is going to accelerate the Cloudflare platform to be the best in class and hopefully not complex and bloated.
I'll sound smug saying it but this is always, always inevitable from the moment Deno took VC investment. Either it was going to be successful enough to take over everything (and it wasn't going to be) or it would end up acquired/shut down.
I know Node is boring but it's not going anywhere.
We’re in an interesting time for developer tooling. It’s easier than it’s ever been to develop new tools, but harder to monetize or maintain them. We need to figure out what sustainable OSS looks like in the AI age.
Genuine question. Why are companies buying our runtimes ? What is the advantage ? Maintaining open source and having more adoption in specific softwares like runtimes and programming languages helps keep software more robust and reliable right ? Am I getting something wrong.
In this specific case, it's probably just aqui-hiring. There's a ton of incredible talent at Deno and Cloudflare can pay them a lot more
Also Deno was starting to try to increase revenue with stuff like Deno Deploy. If Deno did succeed, they would be a direct competitor with Cloudflare Workers
With Bun I think it was basically a marketing ploy. To show that it can be developed by AI and still useful
If Deno just took payments or at least donations, it would have thousands, or even tens of thousands of paying customers. Instead, they preferred to submit to VC and chase beehives on Deno Deploy territory.
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
It's very sad. I was excited about Deno from day one, and I wanted to see it succeed.
Deno's ability to run TypeScript files - stripping types - was arguably implemented in Node because of Deno. The consolidated tooling approach was a good attempt at solving tooling fragmentation that Node suffers from.
I think for Deno to succeed, it would've had to have been under a non-profit and maybe that can still happen.
It would certainly be nice if someone continued the work. But I wouldn’t hold my breath for it. Seems like an unthankful job (although I’m sure many projects using Demo now would be happy if it’s still supported, at least).
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
I do appreciate that it's not explicitly anti-competitive, but as a biochemist who spent a lot of time thinking about living systems, I am a bit concerned about a budding ecology that has perhaps collapsed <3
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
The first thing I look at the next time I look at a project like Deno would be its governance structure and if it can be bought by a large company. Imagine if what happened here (or MySQL) happens to Postgres!
Big acquisition, but I hope Deno's runtime doesn't get slowly tied to Cloudflare's specific Workers primitive instead of staying standard platform-agnostic.
Deno did bring lot of good ideas and hope some of them will flow into Node, especially full typescript type stripping, package less imports to name a few.
Also worth calling out that if you want to disrupt a major player, you need to be 10x better, not just 2x.
Either way, congrats team. Hope you going on to build something great at Cloudflare.
I was a big fan of deno, so much that I migrated all my cf worker to demo, cause you can run the same engine in there cloud and local/selfhost - perfect no vender lockin(like with cloud flare workers), it's so sad to see it gets shelved.
Edge Functions are built on the Deno runtime today, but importantly, we operate our own infrastructure and don't depend on Deno's hosted services. While Deno is winding down active development over the next year, the Deno team has committed to contributing bug and security fixes until then. And we'll continue our work with the Deno team to incorporate critical improvements to the Edge Function runtime during this transition.
Our next-generation offering, Compute (https://supabase.com/compute), is already in an advanced stage of development and will support Deno as well as other runtimes like Node.js and Bun. We'll provide a seamless migration path from Edge Functions to Compute. Our goal is to make Compute available for new workloads and existing Edge Functions well before Deno's support window closes.
Existing Edge Functions will continue to be supported, and there's no need to migrate today, and no need to stop writing them. Longer term, Compute will give you more flexibility in choosing your runtime, and we expect it to become the recommended path for new workloads.
We don't have a public timeline to share yet, but we'll provide updates as soon as we do.
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
Man the "cute girly sketchbook doodle summarizing a programming thing" is a throwback to a bygone era. I saw that and immediately knew "this is from the late 2010s"
I remember early into my first programming job as an intern in 2017 someone shared a very similar looking series of sketches intended to explain git with cats. I didn't understand it at the time, and then years later when I was much more comfortable with git I took a look at it again and the explanations make just as little sense to me now as it did then.
I wouldn’t have imagined cloudflare acquiring Deno. But AI got into both of them and somehow now it makes sense? It’s wild. Anyhow congrats to Deno team.
So what's the story with JSR sticking around then? Does it already see meaningful use among people using Workers, or do they just really want an escape hatch in case we see more long-term issues with GitHub and NPM?
And does it at least mean the stdlib will see continued development?
It probably does get that advantage that it has had fewer supply chain attacks than npm.
I liked its scoring system for packages and "make the Typescript docs a public part of the package page" and "focus entirely on ESM-first/ESM-only packages". None of that npm does today, so JSR is still the best way I know to find modern and up-to-date/clean packages versus npm just has a nasty swamp of things still in CommonJS for no reason or that will never get upgraded out of CommonJS because the original maintainers are long gone.
I’ve been using Deno’s permission system as a sandboxed replacement for ‘python -c’ for my agents. Hopefully a better supported runtime (in any language) adds a similar permissions system in the near future.
What is it with everyone buying runtimes? — P.S. Deno always felt like it is going to be abandoned, you can't build your work on this much shaky ground...
my recent comment [0]: was deno was the only other tech player building a proper serverless platform to bring Cloudflare workers in an open source manner.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
create a plan to implement a javascript runtime similar to {deno,bun,node.js,whatever} in {Rust,C++,ASM,Go,Fortran} language, use subagents @ max effort, keep building until you're done, follow instructions according to INSTRUCTIONS.md
Disappointing news to see it shut down, but maybe the writing was on the wall after they laid off some of their folks.
I've been using deno for years and built some nontrivial services in it. When deno added support for npm packages, the early days were pretty rough. I ran into lots of issues with packages and spent a lot of time reading random github issue threads. It's been pretty smooth sailing for the last year or so though.
At least I can use ai to help migrate off of deno.
For me Deno jumped the shark when they started trying to be backwards compatible with node and the npm dumpster fire.
For me, the entire thing that made me want to use Deno was it was a clean-sheet rewrite that was aiming to overcome the negatives of node and npm. It was a breath of fresh air. Yet overtime they basically ended up just trying to replicate node. Such a shame.
Still, I like cloudflare's offerings so I'm very interested to see what they come up with after work on worded/celld
Especially with LLMs automating all sorts of code and operational aspects, we could do Tcl/Lua type whitelist sandboxes where the application can only call a limited set of functions.
Man, this year has been nothing but bad news for me. This is disappointing, and really makes me question what is the point if even open source is now this easily enshittified or "killed by [insert big tech co here]." I've spent years now using Deno nearly exclusively for new projects, and saw it as the most sane JS server runtime. This also makes me hesitant to use anything with Ryan Dahl's name on it ever again.
I still find it breathtaking that anybody ever thought it was a good idea to develop a web server in a single-threaded language. And apparently huge numbers of people still do.
Congrats. But also terrible news for the ecosystem; this project was a bit doomed from the start, and they acknowledge it multiple times (implicitly), but nice to have competition, I guess.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
> The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places.
Honestly, this motion right here is the death of open source - the rug pull. I no longer can trust any open source project won't get bought up and sunsetted. I'm glad open tofu and valkey and Linux exist to serve as a counter example but this makes me sad.
It's not the death of open source. It will probably be the death of small company open source. Either 100% community/non profit or 100% big corporation and users check corporate alignment with project goals.
I took the plunge and ripped out all my (“open source”) Magento shopfronts and reimplemented them from the ground in…… 2 hours. And it is so much more performant to boot.
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
So both major (and the only meaningful) possible Node alternatives have been absorbed into proprietary monoliths in the last year. We all know how well the Joyent years went, RIP to open source innovation at this point.
No if that were true they wouldn't be stopping development of Deno, which as it stands sits in the best position for codemode given it's granular sandboxing.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
I'd guess Deno failed because of the original decision of not supporting node_modules, instead went with a different way of handling dependencies. Else the native typescript support would most likely had pushed them to bigger success past nodejs.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
Sorry, but even factoring in that this acquisition carries over the existing customer base and goodwill, this is still **** (censored because I aim to stay polite). Deno is factually speaking a one to two week project at this point (proven by the numerous JS runtimes already on the market). I genuinely do not see how this makes any sense whatsoever. If Cloudflare was seeking to hire the team behind Deno they could have done it at a fraction of the price paid. This, naturally, assumes they did pay anything and I can't be bothered to look up the exact $$$ amounts.
I think Deno’s VC money ran out (see the layoffs a few months ago) and Cloudflare offered a stable, well paying job, maybe with stock options.
Just this morning I checked the Deno blog (again like so often in recent weeks) to see if they are still alive. The number of mentions in Hacker News posts and comments was zero in recent weeks. The project was basically dead or abandoned already. Sucks, because I went all-in on Deno.
So what am I supposed to do, just congratulate them and avoid any critical thought so as not to get downvoted into negative territory on my first day commenting on HM after 5 years of staying away for this exact reason?
What happened to React Native? Is it going to be discontinued as well?? We have quite a few customers using it, so we provide a SDK for it. Could be interesting if we can retire that.
This is actually awesome news believe it or not. I'm excited b/c i think there's a lot of potential in the world w/ deno's team being on solid footing w/ cloudflare.
I know the runtime is in trouble, but i'm not as worried tbh b/c the principles deno championed are going to keep going.
As a bystander, I'm excited by this. I don't know what it'll be, but I have a sense some interesting, powerful, and secure new ways of shipping code could come from this marriage...
- there are companies offering serverless functions on their platforms, powered by Deno Deploy. Can this acquisition be an attempt to kill competition?
- Cloudflare now owns a huge chunck of JavaScript ecosystem, like Vercel. They are buying like countries that are arming themselves for war. What is the strategy here?
Time and again, staying on the mainstream node/npm stack continues to be the validated choice. I've seen this happen with io.js, bun, and deno. The situation has been similar for yarn/bun and most alternatives on the package manager side.
Of course, that's not to say the work done on these platforms was wasted. The divide around io.js was meaningful to getting things moving faster and change the governance structure. Deno and bun both showcased things Node could be doing better and some of that was folded back in.
And in spite of all those past experiences, I still find myself using pnpm over npm today. I'm sure npm will continue to evolve and eventually the critical features of pnpm will just be part of core npm. But the gap today is massive enough that pnpm over npm feels critical. The disk usage and performance wins are life-changing for daily work and CI flows.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.
If it was truly “so many companies” then they wouldn’t be in this situation… reading between the lines here it’s clear Deno was not a successful project.
Exactly why any company that cares about long term maintenance should stick with Node.js except in cases that justify alternative runtime.
I wouldn't be surprised if Bun is abandoned at some point as well.
(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)
You can migrate off deno in a single day. It's not a big deal.
Doesn't supabase edge functions run on Deno? I presume this is huge setback for companies like that and their users.
But then again considering there's no barrier for entry to develop runtimes now, I guess these companies are just going to develop their own.
Congratulations to the Deno employees.
Whoever did it, decision maker was reckless and should his job should be reassessed. This is not surprise, similar will happen to Bun as well, just matter of time.
I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.
Node is old I’ll give you that. Dependable is debatable.
I went all-in with bun. Did I bet wrong?
Node was once the shiny new thing, so that argument is irrelevant. Deno got a lot of traction by promising to fix Node’s issues, some people trusted that promise, and Deno just didn’t deliver.
How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.
Deno always felt like a "people pot", the kind of company whose sole (but unstated) purpose is to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company who can actually utilize them. The actual product was secondary at best.
Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.
I wonder how much they have financially contributed to Deno.
Surely they could fork it and just continue it OSS?
Asking as a non-JS person - what's the cost and effort to switch?
At least open source gives them an opportunity for the community to find a way to support it going forward. But I suppose that's just table stakes these days.
Radical idea here, but maybe those many companies could _fund_ the development of key components of their infrastructure.
It's why I usually look more closely at the comments here than at the story for stories like this.
I was really surprised that cloudflare was acquiring deno to be honest, I have written about this here before, Deno was always sort of dead to me due to how little they cared for compat of all kinds (nodejs, CJS, backwards). It was refreshing to see bun care a lot about it (well, now its on a different path in other ways).
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
>So many companies went all-in on Deno in recent years.
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
Do they also do their front-end in Dart?
I mean, if you have any test suite worth a damn, then this should only cost a few dollars in tokens for the average team and be nothing more than a minor inconvenience.
They can fork it.
Honestly migrating back is trivial now. It just isn't that big of a pain.
> So many companies went all-in on Deno in recent years.
They should hire a few devs to develop it then.
Seems like an extremely risky thing to do. Luckily they can keep maintaining it and improving it if their business is truly dependent on it.
> So many companies went all-in on Deno in recent years.
I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.
Anybody who has been bitten by the many issue with Yarn over the years can tell you, just stick with stock tools and deal with it.
Well, the license Deno is distributed under explicitly warns you (sorry for all caps):
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.
See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.
QuickJS works fine for yt-dlp and is way smaller: less than 1 MB vs 34 MB + its many dependencies for Deno.
See https://github.com/denoland/deno/discussions/9811
For asynchronous downloading of huge media files, speed should not be a priority?
As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad". They might reevaluate that in light of things being generally fine and losing their precious handcoded runtime choice.
So "Deno" isn't joining Cloudflare, Deno is effectively defunkt and its former team is joining Cloudflare.
jsr is moving to cloudflare.
‘Acquires’ is an interesting word, given they’re hiring people and sunsetting the product. They didn’t buy Deno, they hired the team that built it and that forces them to abandon the project.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
I don't like how that's in the Deno post but gets no mention in the Cloudflare post. Seems like a pretty important detail!
I think it’s covered appropriately for the audiences. The two posts are for different audiences and purposes. The Deno post by Ryan is for the Deno audience, which is mention at the top of his writing on the Cloudflare post that is for a broader audience of what this means for the Cloudflare audience: “For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.”
FWIW both Ryan and Kenton are very transparent in person, in public, and online over their professional careers. They will and do openly change their minds based on new information and opportunities as time goes along. Both are now founders of open source projects acquired by Cloudflare for the technical architecture talents seeing a future that they would like to build.
Definitely negative karma points for Cloudflare.
Oof.
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
RIP Deno
I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land. I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
[1] https://x.com/KentonVarda/status/2108559594691690663
[2] https://edgejs.org/
> since it push on semantics that can only be run on Cloudflare infrastructure
No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).
Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.
This was emphasized in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
> now Deno will not be developed further.
that's an interesting reflection on the nature of open source - in theory the source is there and "the community" could conceivably continue development. especially in the case of something like deno where the people most motivated to keep it alive are already programmers. but the reality is that however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.
hopefully that single entity can be a consortium of companies invested in using the runtime, sort of like opentofu recently.
Dumb question: Why do we need many independent Node.js runtimes?
Why Edge of Node.js?
So they don't want to buy Deno, they want to buy the team to work on something cloudflare specific.
I'd say it's durable object specific. Both team deno and cloudflare (and many others) have been won over by the paradigm. Cloudflare is just the primary implementers of it as a strong example of an actor-based programming model at infra layer, but others have been trying to push it (Rivet, and TerseAI's durable actors, celld)
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
Why would they acquire them then shut it down? Is there a reason for that?
Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.
Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.
Acquihire - they’re acquiring it for the team behind it to eventually develop proprietary software
Hopefully not to stop celld, the cloudflare Durable Object compatible impl. https://github.com/denoland/celld https://news.ycombinator.com/item?id=49185430
Phrased as it being merged into the existing, but I can't help but fret a bit. Is cloudflare willing to let their own core compute product be something available to the world? Absolutely sick wins if so. But I worry celld pretty reasonably seen as a threat.
acqui-hire
Why is cloudflare even buying deno in that case? Is it an acquihire?
Funny that with Bun being acquired by Anthropic, if this big bet on AI doesn't work out we'll end up right back where we started; Node. Obviously Deno will still be OSS, Bun would likely end up that way too, but you get the idea
but even in that scenario, the node competitors absolutely spurred new energy and innovation in node, as node themselves have acknowledged
This is the real headline... and more so that it has been hidden away.
Why would they buy something just to potentially kill it?
The CloudFlare blog concludes with:
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
We don't completely know what it will look like yet either, but it will absolutely be open source -- as workerd and celld are both already.
So why cloudflare buys them? Just to do the MS thing?
The fate of many forks, while reference implementation keeps chugging along adopting the most relevant features.
Deno is decidedly not a fork for Node.
What is in this for Cloudflare? Just the employees? I can't imagine hiring these days is that hard that it's worth creating this much ill will.
This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?
Genuine question, is this legal under US anti-monipoly laws?
I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.
Surely buying a company out only to close their main offering is defined as anti-competitive?
US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.
But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.
(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)
(There might be something the state of California could do, but I don't know how much they want to get involved.)
I'm not sure if it is legal or not, but it happens all the time, and nothing is done about it.
IMHO, it shouldn't be allowed.
Do you think Deno was real competition for Cloudflare, and now that they've merged we don't have alternative options for goods/services that are mostly essential?
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
> but didn't Facebook get in some trouble for purchasing Instagram
They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.
In what sense did deno compete with cloudflare? It is a niche runtime and cloudflare is a cloud platform
this is SO SAD. i've spent months on my deno tui
https://github.com/ubernaut/exotui
https://ubernaut.github.io/exotui/
Pretty cool looking project you made though. Sorry.
Damn that sucks. I love Deno. It really should have ‘won’ the runtime race. Oh well.
It's more honest than other silently unmaintained project.
Thats really upsetting ngl.
What's the business logic behind buying and sunsetting?
You get a skilled team who have been thinking about and working on the problems you want to solve for years.
Hiring an entire team that works well together is a big accelerant compared to finding and hiring the right individuals and trying to form that team.
See also Ryan Dahl's comment here: https://news.ycombinator.com/item?id=50019911#50023277
I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.
Interesting. I guess open source is not as dependable as it used to be
Hmm ... so why would they acquire it to let it die?
Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.
Competitors use it as their serverless JS runtime, likely as simple as that.
This is exactly what I was wondering.
Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.
Why buy it then? The staff?
i guess bun won
> So unless someone else picks up development, Deno will no longer be supported.
Isn't that what FLOSS is all about?
I'm saddened by this, and will now need to plan for some migration work in a couple of production projects. Sigh.
Shame- it is my favorite Markdown formatter.
The word 'skitzo' is pretty offensive to people who actually suffer from schizophrenia, maybe try 'unhinged' or 'bizarre' or something.
Anthropic bought bun.sh
Anthropic acquired bun
That was bun, not deno
I mean we already have a winner (Bun) and it just means that Deno has admitted defeat.
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.
Kinda feels like a rug pull, similar to Bun.
Not even close as Bun is still being actively developed, albeit with less fervor.
Which any existing user can just do?
Can someone explain to me how you "acquire" an open-source project?
I know it's been done for years and reflects so basic a misunderstanding I have about the ecosystem.
Also, if your goal is to commercialize, why open source at all anymore vs have a free tier and ecosystem?
I'm so bummed about this. Deno is by far my favourite JS runtime. I could sense this coming for a while now, but I was hopeful and just waiting to see what happened. Here we are. I'm glad I don't need to get off the runtime immediately. Sad we won't see any innovation like we did in the last 8 years or so.
I hope workerd at least adopts Deno's security mechanisms so it functions as a better sandbox.
One of my favourite projects of 2026 was a configurable LLM harness built around using deno as the runtime. The idea is that the configuration builds a state machine-driven program which is bundled into a binary that can only provide access to the I/O your code explicitly needs. I used it primarily to build interactive programs for colleagues which allow some LLM magic to occur without needing to worry about what they would do with Claude Desktop handling the same data or accessing the same machines and so on. It also allowed for testing local LLMs in deterministic patterns. How do they reason about what to do next when they can evaluate the possible states they can enter, based on the current context? It was really fun. Now I don't really know how I'd rebuild it, knowing I wouldn't use Deno. Maybe that's worth learning anyway.
For what it's worth, workerd has some pretty aggressive sandboxing too. I'm a bit biased but ask your favorite LLM about it.
I loved early Deno and am sad to see it die. I invested heavily in the Deno ecosystem because of Ry’s initial vision for it.
But I stopped because I saw this coming the moment they changed course and started putting npm compatibility as a priority. Deno’s surface area went from beautifully simple to very bloated. I think they felt the pressure of VC funding and just gave up on rebuilding Node from first principles.
The silver lining is that early Deno was so good that Node copied some of its features. So at least we have a better Node now.
Bun's adoption rate (because of its NPM compatibility) was the forcing function; not VC funding. Deno could pursue a slow-and-steady better-will-win approach vs. Node until another runtime competitor appeared with a more seamless node integration. In fact, the VC funding is what made the slow-but-steady strategy possible in the first place.
Strong disagree. Deno could have been a cheaply run open source project with corporate sponsors and could have pursued the slow and steady approach. There's no reason to feel pressure from competitors unless you want to if you're forging a genuinely new path. "Clean break from Node" was the differentiator. Once they abandoned that the reason for using it went away.
The moment they took on VC funding they had to care about competitors and also had to move away from the framework to things like Deno Deploy in pursuit of money.
They basically gave up the day they decided to become npm compatible. That was the day Deno died.
That’s the day I switched to Bun
Enshittification is inevitable once a company takes VC funding
That's the correct answer, the rest is cope.
"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.
I'm trying to understand this. Cloudflare wants the people to work on different priorities or cloudflare wants deno to die?
In the case of the latter, I'm wondering why. Most of cloudflares architecture like workers support js runtimes so wouldnt investment into deno be more strategic than other priorities
I'm more thinking of "Deno (the company) lost interest/faith in Deno (the runtime), so they were looking for an out". They like working with runtimes, so Cloudflare is probably a good choice.
I guess this is why so much core staff left suddenly some months ago.
It’s likely that this could be true but they simply have something else they want the acquihired to work on and feel Deno would be a distraction. At least they’re being honest with it instead of letting development stall and all the ill will that comes with the usual slow death by acquisition
Brilliant take, this is why I come here. Cut through the "our amazing journey" BS.
RIP, my favorite JavaScript runtime, and thank you. You were too secure for this world.
What kind of business move is this for Cloudflare? celld is a more complete Cloudflare-at-home runtime than current workerd. What does Cloudflare stand to gain from commodizing Workers?
I'll say that although I'm not really a Cloudflare Workers user, I've been eyeing workerd and celld with interest. The idea of a complete backend in a box appeals to me (see also: PocketBase, Algernon). At the same time, the acquisition means that another company won't acquire Deno for celld.
From the Cloudflare blog post, this quote from Kenton Varda (head of Workers):
> "Lock-in" actually hurts us — that's why we went open source If there were truly no escape hatch from Workers, then some of our largest customers would never have signed on with us in the first place.
> [...]
> Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd. I'm incredibly excited for this work — I will personally be using it to host an instance of Cloudflare OS in my home.
Love the transition from being secure on my machine to being secure on somebody else's machine. This offers additional security by making it impossible for me to move the code anywhere else. Which solves the common security problem of me moving my business anywhere else.
To kill celld and potential competitor early? AFAIK, there is no a single Durable Objects alternative at the moment? It's better that way I guess.
> there is no a single Durable Objects alternative at the moment
If you live in Elixir land, there's this repo from the Phoenix team, which is quite good. It has pluggable storage, and EKV (https://github.com/chrismccord/ekv) is supported as "batteries include" type storage adapter.
https://github.com/phoenixframework/durable_server
There is rivet and terse
https://github.com/elyase/awesome-object-storage-native#stat...
Celld seems great, did not even know!
Meaning better that there is no alternative?
Rivet
So the developer tooling consolidation/acquisitions continue... hmm!
- Cursor -> SpaceX
- Astral/uv -> OpenAI
- Stainless -> Anthropic
- Bun -> Anthropic
- Astro.js -> Cloudflare
- Deno -> Cloudflare
- VoidZero (Vite, etc.) -> Cloudflare
- NuxtLabs -> Vercel
- Hugging Face -> NVIDIA
- ... what else?
Shopify bought Remix and Tailwind and hired the maintainer of Preact
Didn't we use to say that the startup exit strategy was to sell to Yahoo. I guess now a days it is sell to AI
Scala -> Vertiseit AB this year, I was going to joke about someone acquiring Scala but found out it really happened
GitHub -> Microsoft, or is this too old
Different scala from the programming language (not sure if you knew that already, I did have to check).
- Warp -> OpenAI
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
Replit is not acquired by Anthropic
Svelte -> Vercel
and also React
Llama.cpp -> hugging face -> NVidia
Dioxus -> Cognition
SLURM -> NVIDIA. Pretty big deal for the science community.
W&B -> CoreWeave
EdgeDB -> Vercel
BetterAuth -> Vercel
TanStack next?
tanner seems not-acquireable
A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.
I've been following celld since it was announced. Bootstrapping both durability and coordination off object storage simplifies so many things for self-hosting. (Yes, ironic that self-hosting has a cloud dependency, but in this case I think justified because S3 has become a widely supported protocol that you can run yourself too).
Will be curious to see the details on exactly how that model makes it into workerd.
The plan is to bring the celld model to workerd: run a fleet of workerd instances that use a bucket for coordination and storage. Building on workerd, instead of a separate runtime means our effort isn't split and that APIs are exactly the same in both CF and self-hosted. And of course the deno team will help improve the worker runtime itself.
>A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.
I think people are focusing on it because if you've built your business on Deno, then the "Deno will have no support in 13 months time" is a bit of an existential risk, and will be a huge time-sink for your team. So it's far more interesting to most of the people reading this page on HN, because HN is full of people who are first-adopters.
Maybe it’s time to ask AI to rewrite those projects ;)
check rivet and terse
https://github.com/elyase/awesome-object-storage-native#stat...
I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively. Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now.
Don’t have a strong opinion on any of this, but it’s actually super normal for anyone who helps run a business to push hard and try to grow it.
Things don’t always shake out as you plan
Investors are a helluva drug
Yeah they just made me migrate my blog to their new cloud platform four months ago.
That's a pretty uncharitable take. It literally only exists because of him, he pushed hard for it for years, and now he's decided not to anymore it leaves a bitter taste? What do you want him to do?
Meh, those types of large scale migrations are just a very short prompt nowadays.
specially deno to bun
What's with the downvotes? Do people doubt that this type of work is something AI is particularly good at? Or is it just resentment against the resulting fact that making the right architectural decisions isn't as important as it was?
I have felt very misled with the communications around this like this X post. They say Deno + Cloudflare. But at the bottom of the post it's clear that Deno is RIP.
https://x.com/deno_land/status/2108543358197207048 (https://archive.is/H4GLt)
The Cloudflare side is also worth a read: https://blog.cloudflare.com/deno-joins-cloudflare/
To summarize my feelings: Shit!
Deno's ability to import directly from a package registry or even git repo in a standalone TS script without requiring a package.json or similar 'meta-data' file was actually really nice for shell scripting stuff. AFAIK node.js still can't do anything similar?
`zx --install` will give you this. It's quite handy and enjoyable generally for shell scripting in ts/js. https://google.github.io/zx/cli#install
if you're not locked to javascript you could use python with pep-723[1] to declare inline dependencies
1: https://peps.python.org/pep-0723/
I just migrated that project away from Python to TS :D (cries in corner).
Python package management is a horror show.
Deno should never have been a business - there's no business model.
And worse for Deno - nodejs may not be great but it's good enough.
And may you never have an incumbent competitor that is is "good enough" - it will be your downfall.
I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.
of course i’m only talking about deno, the technology not deno, the cloud service.
> I’m happy if this means Deno is able to get a second impulse
Bad news, sorry, the article says:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Sounds like Celld will live on within workerd, Deno is over.
> I’m happy if this means Deno is able to get a second impulse.
From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
read the blogpost, they are discontinuing deno after 1 year
The fact that Deno development is being suspended doesn't mean the community can't step in. The Deno runtime is licensed under MIT. Such forks might be impulse to grow even further.
it’s open source. i’m hoping it gets picked up by the community. maybe i’m just too hopeful
Damn. Deno is a super old project, in 2018 the Nodejs creator did the talk "things I hate about NodeJS" and introduced Deno. It's 8 years ago now, and clearly even though the project was known by most Node users, it didn't gain any traction at all. I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ? Anyways Node will keep evolving and implement new features, new standards, optimization. I think it's super risky to move to an alternative. In the age of the LLMs, if you wanna get out of Node, you better translate all to native Go or Rust.
8 years is not super old, or even old. It's important to understand software maturity cycles for core components.
"old" is relative term. Given @TheRogue's account is 4 years old, maybe new to field. If so, it feels "old".
I understand your sentiment of justifying not being "old". but you gotta bring up "legacy code".
"Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
So either @TheGuardian is discussing about the age of software relative to his/her perspective or confused "legacy code" without understanding deno code base.
It may not be old, but it sure hasn’t caught on much after 8 years. I did remember a lot of posts about migrating cloud functions/lambdas to deno initially, but not much since.
I’m taking the stance that no news is bad news here. If it was good, people would be doing Resume Driven Dev with deno and we would be buried in those articles. Alas.
Also it didn't hit 1.0 until 2020 so it's more accurate to say it's 6 years old.
It's not that old, but it's old enough that it should have gained a bit of traction, it should have been mentioned in more discussions etc. And ultimately adopted more. It's purely a gut feeling though because I didn't run any numbers
Node itself was only 9 years old in 2018
> I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ?
Well node and bun sought to solve the same problems after Deno demonstrated a path. They got to learn from Deno's mistakes as well.
The main thing was the permissions model and the other runtimes in fact did not learn from it. And there were real big consequences to the node's insane package management model recently.
You can also see that JS developers don't really care about any of this stuff by reading the comments here, people don't even mention this and mention native typescript support like it is such a important thing to have for a significantly large/long-running project.
To me Deno died the day it decided to not support npm packages and died again when it started supporting it.
Ironically the reason why I hated it when it was introduced was the reason why they added support for npm (i.e. absolute URLs don't support semver and therefore you will load multiple versions)
In what way does supporting npm packages compromise Deno's design? I don't know a lot about Deno but thought it was more about rewriting in Rust, more batteries included like native TS support, and more secure defaults.
Once Deno's direction became clear, success seemed unlikely.
Congrats on the exit :)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
Oned maybe.
And then Danone.
This one might have to be spooned
Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.
Whatever allows you to make stuff is good enough.
you are definitely right, thank you for this reminder, it's just that I'm a bit tired of managing trash like NodeJS
What's wrong with NodeJS or Bun?
One year of runtime support and six months for Deploy is a scramble. I can’t even imagine how this feels for any CTO who bet on Deno.
It sure looks like they saw Bun eat their lunch and decided there was no reason to keep competing.
Not going with `node_modules` might be just as big a mistake for Ryan Dahl as introducing it originally.
I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless
Cloudflare could make the biggest impact by doing something similar to AWS DSQL. There are very few options in the multi-region replicated space, and it ties in nicely with their edge workers.
D1 is their bet there but considering hyperdrive, a real Postgres would be cool.
I also wish they expanded jurisdiction more. I worked at companies that couldn't use Cloudflare because of specific location requirements in contracts
Yeah. D1 is nice and easy but a serverless postgres offering would make a significant difference.
Planetscale?
I wonder how this will affect Bunny's competitor to Cloudflare Workers, Edge Scripting [1] -- which runs on Deno.
[1] https://bunny.net/docs/scripting/
I'm very surprised they are not running with the runtime. That seemed like Deno's secret sauce? The rest of it is very aligned with Cloudflare already, deploy, kv, workers, etc seems like the lower hanging fruit.
It's almost certainly not worth it. Having less software that you can keep more reliable is almost always worth it over having more software just because it's 10% faster or whatever. This isn't always true but it's mostly true.
Very unfortunate. I’ve been using Deno for years and recently embedding the runtime into applications/platforms for agents. I’ll continue to use it and hope a community springs up.
I believe so. Deno is too good to just die off.
RIP Deno. Goes into the bin, after Bun.
For a service that has its tentacles all over the internet, you'd think they would prefer native code for the cost savings.
All of this just re-informed my believe to stay with true and tested systems that have survived decades. C if I fell confident and Common Lisp otherwise. Both standardized, have been around for ages, and they don’t disappoint.
I feel bad for anyone that now relies on Deno. And as good as Cloudflare might be for some things, I also feel bad for anyone relying on them.
Didn’t they have a flashy lawsuit to free the JavaScript trademark? What happens to that now?
No indication cloudflare would pursue that yet that I see.
It looks like, after Oracle kept on pushing out the deadline for a certain step in the suit process, the parties are in settlement negotiations now [0]; the motion was granted [1], so we might see more info after October 28th.
[0] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno... [1] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno...
Pretty sure that was just for marketing.
I'm very sad Deno is going away, even though I've never used it nor did I plan to use it.
It is a bit hypocritical in a sense. Similar to how I was sad that a local restaurant recently closed down. In the past two years I went there maybe three times total. But I just liked having it there as an option.
Deno had a ton of good ideas but I just never felt confident that it would have the lasting power. Some of the early decisions, like their initial refusal to fully support package.json and the npm eco-system, made me unsure of their suitability as the basis for a business.
But I always wanted them to succeed. In the same way I always wanted Heroku to succeed even though I never used their service.
More options are better. But I guess "use it or lose it" applies. Did I dodge a bullet or contribute to the downfall?
Remember "choose boring technology"?
I had to evaluate Deno vs. Bun vs. Node for a project two years ago, and chose Node. I think Deno has good ideas but often times these projects cannot reach escape velocity, especially when they're constrained by VC motives.
It's really interesting folks at CF and Deno making this decision while unikernel slowly integrate into mainstream cloud computing as Prisma and Netlify adopting Unikraft. With AI is getting better each day there will comes a day when people be like "why we still running javascript in server?"
I was rooting for Deno so much as I was fighting with node for years. Luckily I made full transition from JS last year and not comming back.
What did you transition to?
Node always felt so annoying to deal with. I was really excited when Bun and Deno were coming up. Pour one out.
It seems VC money is not really compatible with open source
Maybe they all learned their lesson from Docker giving away the entire product for free
I hope so. So far it mostly killed projects.
This shows that there was no money to be made in their business model and they had to sell to make up for the years or losses accumulated.
Does anyone know how many paying Deploy customers there were? The post only offers migration help to paying customers and gives them six months, which makes me think the number is small enough to hand-hold. Millions of runtime downloads and a few hundred accounts on a paid plan can both be true, and only the second one pays for a team.
This is a real bummer. Work never adopted Deno but I love their model, security posture, and the standard library. I've been less interested in typescript recently, but it has turned into the default for frontend.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
Last year it was bun, and now it is - Deno!
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
People need to eat and pay rent. Can’t survive on just goodwill.
https://theoatmeal.com/comics/exposure
> What's happening to JS platforms?
They took on VC funding.
This might not be seen in much favourable light by many but IMO Cloudflare has the most elegant serveless PaaS as I have seen to date.
The design and architecture is extremely minimal to the point that all of it can be explained on a single A4 page with a 14pt font including D1 + Durable objects. And I hope that it stays that way.
It has all the primitives that you can wish for to build a software system on top of it be it queues, long running jobs, workflows, pipelines, email handlers, cron jobs and even built in AI models ready for you to be invoked.
ATM - it is extremely cheap, reliable, simpler and more capable than anything out there. Deno itself had very little scope anyway because almost no developer tooling is sellable in this environment even more so post AI. Therefore, it is going to accelerate the Cloudflare platform to be the best in class and hopefully not complex and bloated.
I'll sound smug saying it but this is always, always inevitable from the moment Deno took VC investment. Either it was going to be successful enough to take over everything (and it wasn't going to be) or it would end up acquired/shut down.
I know Node is boring but it's not going anywhere.
I tried out deno desktop to build a desktop app and I liked it.
With cloudflare being a cloud company I am pretty sure that building native desktop apps is not exactly their highest priority.
I think I'll have to look at options again.
We’re in an interesting time for developer tooling. It’s easier than it’s ever been to develop new tools, but harder to monetize or maintain them. We need to figure out what sustainable OSS looks like in the AI age.
Genuine question. Why are companies buying our runtimes ? What is the advantage ? Maintaining open source and having more adoption in specific softwares like runtimes and programming languages helps keep software more robust and reliable right ? Am I getting something wrong.
In this specific case, it's probably just aqui-hiring. There's a ton of incredible talent at Deno and Cloudflare can pay them a lot more
Also Deno was starting to try to increase revenue with stuff like Deno Deploy. If Deno did succeed, they would be a direct competitor with Cloudflare Workers
With Bun I think it was basically a marketing ploy. To show that it can be developed by AI and still useful
In this case, they're explicitly not buying the runtime. They're killing the runtime.
A bit worried what will become of https://github.com/denoland/rusty_v8 as it still is the best maintained (?) and featured binding of V8 for rust.
rusty_v8 isn't going anywhere - we'll keep maintaining it and will be working towards integrating it into workerd
If Deno just took payments or at least donations, it would have thousands, or even tens of thousands of paying customers. Instead, they preferred to submit to VC and chase beehives on Deno Deploy territory.
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
It's very sad. I was excited about Deno from day one, and I wanted to see it succeed.
Deno's ability to run TypeScript files - stripping types - was arguably implemented in Node because of Deno. The consolidated tooling approach was a good attempt at solving tooling fragmentation that Node suffers from.
I think for Deno to succeed, it would've had to have been under a non-profit and maybe that can still happen.
It would certainly be nice if someone continued the work. But I wouldn’t hold my breath for it. Seems like an unthankful job (although I’m sure many projects using Demo now would be happy if it’s still supported, at least).
Deno was dead the moment they went all in with being compatible with Node. Meanwhile, Bun's only raison d'etre is the lack of TCO in V8.
Please be sure to read the post on Cloudflare's blog, it's not just fluff:
https://blog.cloudflare.com/deno-joins-cloudflare/
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
I do appreciate that it's not explicitly anti-competitive, but as a biochemist who spent a lot of time thinking about living systems, I am a bit concerned about a budding ecology that has perhaps collapsed <3
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?
I don’t know that many people reading this particular thread care whether this is a good business decision for Cloudflare.
Most of us are here because we’re curious what it means for Deno specifically and FOSS TypeScript runtimes in general, since Bun was also acquired.
The first thing I look at the next time I look at a project like Deno would be its governance structure and if it can be bought by a large company. Imagine if what happened here (or MySQL) happens to Postgres!
gets acquired and then kill the project, nothing's new
If this was done to kill celld as a runtime that would be unfortunate.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
On the contrary. Please read my part of Cloudflare's blog post here: https://blog.cloudflare.com/deno-joins-cloudflare/
Sounds like the opposite: They are killing Deno to work on celld
Big acquisition, but I hope Deno's runtime doesn't get slowly tied to Cloudflare's specific Workers primitive instead of staying standard platform-agnostic.
Deno did bring lot of good ideas and hope some of them will flow into Node, especially full typescript type stripping, package less imports to name a few.
Also worth calling out that if you want to disrupt a major player, you need to be 10x better, not just 2x.
Either way, congrats team. Hope you going on to build something great at Cloudflare.
I was a big fan of deno, so much that I migrated all my cf worker to demo, cause you can run the same engine in there cloud and local/selfhost - perfect no vender lockin(like with cloud flare workers), it's so sad to see it gets shelved.
What happens to Supabase?
(Supabase employee)
Edge Functions are built on the Deno runtime today, but importantly, we operate our own infrastructure and don't depend on Deno's hosted services. While Deno is winding down active development over the next year, the Deno team has committed to contributing bug and security fixes until then. And we'll continue our work with the Deno team to incorporate critical improvements to the Edge Function runtime during this transition.
Our next-generation offering, Compute (https://supabase.com/compute), is already in an advanced stage of development and will support Deno as well as other runtimes like Node.js and Bun. We'll provide a seamless migration path from Edge Functions to Compute. Our goal is to make Compute available for new workloads and existing Edge Functions well before Deno's support window closes.
Existing Edge Functions will continue to be supported, and there's no need to migrate today, and no need to stop writing them. Longer term, Compute will give you more flexibility in choosing your runtime, and we expect it to become the recommended path for new workloads.
We don't have a public timeline to share yet, but we'll provide updates as soon as we do.
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
> what should I choose and why?
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
There's basically no reason not to just go with Node as 99% of projects out there do
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
There's just one worthy of using for fresh project: Bun.
Deno was never going to be a thing anyways.
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
I'd just go with Node, it supports TS natively now.
Even if official development ends next year, the pressure Deno put on Node to modernize TypeScript support and standards was worth it
I still remember this cute drawing from years ago outlining the things Ryan regret about Node
https://imgur.com/a/XFAMzOV
Man the "cute girly sketchbook doodle summarizing a programming thing" is a throwback to a bygone era. I saw that and immediately knew "this is from the late 2010s"
I remember early into my first programming job as an intern in 2017 someone shared a very similar looking series of sketches intended to explain git with cats. I didn't understand it at the time, and then years later when I was much more comfortable with git I took a look at it again and the explanations make just as little sense to me now as it did then.
This news made me rethink about building on Bun. It's a bit iffy now.
I wouldn’t have imagined cloudflare acquiring Deno. But AI got into both of them and somehow now it makes sense? It’s wild. Anyhow congrats to Deno team.
Really sad to see this. I've built projects on the Deno runtime and to see it end in 45 words...
I guess the positive is that at least Deno pushed Node.js to evolve.
So is dead for all intents and purposes. And this would’ve happened to Bun if it hadn’t found its killer app (Claude Code).
Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.
What is the value prop of Deno?
Well this is fucking depressing.
So what's the story with JSR sticking around then? Does it already see meaningful use among people using Workers, or do they just really want an escape hatch in case we see more long-term issues with GitHub and NPM?
And does it at least mean the stdlib will see continued development?
It probably does get that advantage that it has had fewer supply chain attacks than npm.
I liked its scoring system for packages and "make the Typescript docs a public part of the package page" and "focus entirely on ESM-first/ESM-only packages". None of that npm does today, so JSR is still the best way I know to find modern and up-to-date/clean packages versus npm just has a nasty swamp of things still in CommonJS for no reason or that will never get upgraded out of CommonJS because the original maintainers are long gone.
JSR keeps running - the infrastructure is moving to CF
I’ve been using Deno’s permission system as a sandboxed replacement for ‘python -c’ for my agents. Hopefully a better supported runtime (in any language) adds a similar permissions system in the near future.
Inevitable for a project like this when you take VC money, unfortunately.
If your company does not own an ecmascript runtime ngmi
I just learned of Deno yesterday when setting up some software for the first time. I wonder how many applications depend on it behind the scenes?
What is it with everyone buying runtimes? — P.S. Deno always felt like it is going to be abandoned, you can't build your work on this much shaky ground...
This is sad. I was a heavy user of Deno, though I recognized its likely downfall when they laid off a large part of their team in the last year.
Well this sucks. My blog is based on deno as I wasn't a fan of node.js at the time. I guess I'm gonna have to rewrite my blog engine.
Well this is very stupid. Why not move Deno to be based on workerd or something? or vice versa? throwing it away is such a waste.
This is mostly to be expected.
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
Wow. Just about to choose Deno for something. That not only makes me rethink Deno but ... rethink a lot of things ...
my recent comment [0]: was deno was the only other tech player building a proper serverless platform to bring Cloudflare workers in an open source manner.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
the CF blog post suggests that is what the Deno team will be working on: combining workerd and celld for true self hostable workers/DOs
Does Cloudflare already use Deno under the hood then? Like the Anthropic -> Bun aquisition
Does this mean that celld is dead? No more open source durable objects?
Can we rename title to "Deno is winding down" ? It's not joining cloudflare. the people are
No idea why CF wouldn't just have them to continue working on Deno indefinitely...
Because Deno turned into some quirky serverless technology.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Extremely disappointing...
It's only OpenAI which doesn't have an in-house modern runtime
https://openai.com/index/openai-to-acquire-astral/
They should just go all in with Wasm.
~/.local/bin/codex --dangerously-bypass-approvals-and-sandbox -c 'model="internal-gpt-7-turbo-blackhole"' -c 'model_reasoning_effort="max"' -c 'plan_mode_reasoning_effort="max"'
create a plan to implement a javascript runtime similar to {deno,bun,node.js,whatever} in {Rust,C++,ASM,Go,Fortran} language, use subagents @ max effort, keep building until you're done, follow instructions according to INSTRUCTIONS.md
Wait a day and you're done.
Curious to see whether, in five or so years, we'll see another talk by Ryan Dahl announcing a new JS runtime: doen!
10 things I regret about Deno talk incoming
anthropic + bun vs cloudflare + deno, could it be counter move for building from agent sandbox that runs on the edge?
Cloudflare really be buying up everything
Grats on the bag.
never used deno or paid much attention to it despite all the fancy marketing.
i always wondered how they were making money
so workers would support deno ?
Disappointing news to see it shut down, but maybe the writing was on the wall after they laid off some of their folks.
I've been using deno for years and built some nontrivial services in it. When deno added support for npm packages, the early days were pretty rough. I ran into lots of issues with packages and spent a lot of time reading random github issue threads. It's been pretty smooth sailing for the last year or so though.
At least I can use ai to help migrate off of deno.
https://dbushell.com/2026/03/20/denos-decline-and-layoffs/
For me Deno jumped the shark when they started trying to be backwards compatible with node and the npm dumpster fire.
For me, the entire thing that made me want to use Deno was it was a clean-sheet rewrite that was aiming to overcome the negatives of node and npm. It was a breath of fresh air. Yet overtime they basically ended up just trying to replicate node. Such a shame.
Still, I like cloudflare's offerings so I'm very interested to see what they come up with after work on worded/celld
Gotta say the fate of Deno has been pretty disappointing I had high hopes for it
Can't believe they bought out Vite and now Deno. All our toolchains are getting bought out by military contractors
Deno was a good idea in the Old World of software development before LLMs, and simply doesn’t make sense anymore.
Why? We probably need more sandboxing, not less.
Especially with LLMs automating all sorts of code and operational aspects, we could do Tcl/Lua type whitelist sandboxes where the application can only call a limited set of functions.
Congrats to the team! Sad to see deno go away, it’s a really great tool
This is awesome. The Cloudflare platform is great; being able to run more of it locally is a definite plus.
Man, this year has been nothing but bad news for me. This is disappointing, and really makes me question what is the point if even open source is now this easily enshittified or "killed by [insert big tech co here]." I've spent years now using Deno nearly exclusively for new projects, and saw it as the most sane JS server runtime. This also makes me hesitant to use anything with Ryan Dahl's name on it ever again.
I’m disappointed that they discontinue the Deno runtime. It really is a joy to use.
I think they ran out of money and joining Cloudflare was their only remaining option.
R.I.P.
"entire Deno team is joining Cloudflare .."
Whom did they work for before?
Disappointing. Everything I want to express about this is impolite.
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
really wondering what role celld played in the negotiations
From CloudFlare's side (https://blog.cloudflare.com/deno-joins-cloudflare/) is seems celld was the main point of this - letting the Deno team focus on making workerd self-hosting easier.
I still find it breathtaking that anybody ever thought it was a good idea to develop a web server in a single-threaded language. And apparently huge numbers of people still do.
this makes me so angry. I've literally spent months working on my tui. I hope to god deno keeps going.
https://github.com/ubernaut/exotui
https://ubernaut.github.io/exotui/
Congrats. But also terrible news for the ecosystem; this project was a bit doomed from the start, and they acknowledge it multiple times (implicitly), but nice to have competition, I guess.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
Bun is claude code now. Not gonna touch it.
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
sorry, but who even is still working on Deno? All my friends who used to work on Deno got fired
is this a good or a bad news ?
Killing js on backend is always good, someone needs to buy nodejs and do the same
Fools... I downloaded it for free...
Damn that is a shame. I liked pretty much everything about Deno. Especially great for scripting.
I'll probably move to Rust for scripting I reckon. It's not very mature but hopefully it won't be too much longer.
Fresh was also the best web framework I've used. Oh well.
One step towards a $25K github replacement?
Congrats Ry
Announcing eDon, my rewrite of Deno in Rust!
Edit: Yes, but it's not named after me, which this fork fixes.
It's going to be the first JavaScript runtime to natively support Super Intelligence APIs.
I'm having an LLM replacing all occurrences of "ai" in every API with "si", in the hopes that OpenSI or SpaceXSI will acquihire me.
Deno's already mostly Rust
https://blog.cloudflare.com/deno-joins-cloudflare/
> The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places.
Well, that's pretty big news actually.
Cloudflare is playing a big game ...
Honestly, this motion right here is the death of open source - the rug pull. I no longer can trust any open source project won't get bought up and sunsetted. I'm glad open tofu and valkey and Linux exist to serve as a counter example but this makes me sad.
It's not the death of open source. It will probably be the death of small company open source. Either 100% community/non profit or 100% big corporation and users check corporate alignment with project goals.
Honestly with AI just build it yourself.
I took the plunge and ripped out all my (“open source”) Magento shopfronts and reimplemented them from the ground in…… 2 hours. And it is so much more performant to boot.
> Deno sells out
I read it more as:
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
RIP
Another open source killed
So both major (and the only meaningful) possible Node alternatives have been absorbed into proprietary monoliths in the last year. We all know how well the Joyent years went, RIP to open source innovation at this point.
Node is still there
Holy shit, I used to work on the Workers Runtime Team and I'm surprised!
what’s so great about it?
how about the IP? will the future open source project be DENO or will they have to come up with another permutation.
(I've trademarked ENDO , feel free to DM me for a license)
huhyyy
is this Cloudflare signalling they're going to hard pivot to being an AI company?
No if that were true they wouldn't be stopping development of Deno, which as it stands sits in the best position for codemode given it's granular sandboxing.
</3
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
Isn't bun also written in rust, so can you clarify what your point is here?
I'd guess Deno failed because of the original decision of not supporting node_modules, instead went with a different way of handling dependencies. Else the native typescript support would most likely had pushed them to bigger success past nodejs.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
What a shame. Guess me and the clankers will be maintaining a fork now
i guess bun won?
can yall stop selling out to cloudflare? The continued consolidation of the internet/tech is wild.
Unreal. Another open source project eaten up by the giants of big tech.
Sorry, but even factoring in that this acquisition carries over the existing customer base and goodwill, this is still **** (censored because I aim to stay polite). Deno is factually speaking a one to two week project at this point (proven by the numerous JS runtimes already on the market). I genuinely do not see how this makes any sense whatsoever. If Cloudflare was seeking to hire the team behind Deno they could have done it at a fraction of the price paid. This, naturally, assumes they did pay anything and I can't be bothered to look up the exact $$$ amounts.
I think Deno’s VC money ran out (see the layoffs a few months ago) and Cloudflare offered a stable, well paying job, maybe with stock options.
Just this morning I checked the Deno blog (again like so often in recent weeks) to see if they are still alive. The number of mentions in Hacker News posts and comments was zero in recent weeks. The project was basically dead or abandoned already. Sucks, because I went all-in on Deno.
uh oh
Cloudflare is a publicly traded company.
So what am I supposed to do, just congratulate them and avoid any critical thought so as not to get downvoted into negative territory on my first day commenting on HM after 5 years of staying away for this exact reason?
It was pretty naive to stand in front of that NodeJS train.
Deno is crap so is the StrongLoop team that started it
Welp. All tech eventually gets bought out by military contractors or grows big enough to become one.
Wow, so React Native and Deno both effectively have nails in their coffins. I wonder what's next.
What happened to React Native? Is it going to be discontinued as well?? We have quite a few customers using it, so we provide a SDK for it. Could be interesting if we can retire that.
So Cloudflare killed Deno
Its no longer gonna be supported after 1 year
In that case Deno is not joining cloudflare, it's got eaten.
I invested a lot and use deno everywhere. Can't trust anything these days.
Lets fork it into opendeno. I like to have an all-in-one swiss army knife tool.
> So Cloudflare killed Deno
Uh no. The lack of users killed Deno.
This is actually awesome news believe it or not. I'm excited b/c i think there's a lot of potential in the world w/ deno's team being on solid footing w/ cloudflare.
I know the runtime is in trouble, but i'm not as worried tbh b/c the principles deno championed are going to keep going.
What ? They are literally stopping development in a year.
You think the open source community will be able to continue deno? Did you miss the part where they're stopping development on it?
As a bystander, I'm excited by this. I don't know what it'll be, but I have a sense some interesting, powerful, and secure new ways of shipping code could come from this marriage...
I have 2 questions:
- there are companies offering serverless functions on their platforms, powered by Deno Deploy. Can this acquisition be an attempt to kill competition?
- Cloudflare now owns a huge chunck of JavaScript ecosystem, like Vercel. They are buying like countries that are arming themselves for war. What is the strategy here?
Time and again, staying on the mainstream node/npm stack continues to be the validated choice. I've seen this happen with io.js, bun, and deno. The situation has been similar for yarn/bun and most alternatives on the package manager side.
Of course, that's not to say the work done on these platforms was wasted. The divide around io.js was meaningful to getting things moving faster and change the governance structure. Deno and bun both showcased things Node could be doing better and some of that was folded back in.
And in spite of all those past experiences, I still find myself using pnpm over npm today. I'm sure npm will continue to evolve and eventually the critical features of pnpm will just be part of core npm. But the gap today is massive enough that pnpm over npm feels critical. The disk usage and performance wins are life-changing for daily work and CI flows.