> 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.
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.
> there wasn't a ton of explanation given beyond the general vibe of "ai bad"
I'm vert bullish on AI, but vibe-porting the piece of software you're the main maintainer over a few weeks without letting anyone in the community know and pushing that as a fait accompli to both your userbase and your open source community is definitely the kind of behavior that makes you not trustworthy enough to depend on.
as a counterpoint, your fears are hypothetical so far - nobody on earth cares as much about bun as the bun team and if it was good enough for them it is probably good enough for 99% of users
i think someone who has built their infra on top of bun and have bills to pay care much more about bun stability than the team who get paid by Anthropic to vibecode an entire port to another lang
If I remember correctly, Deno was always priority number 1 due to having a permissions system. Bun's removal due to the rewrite had people complaining using Deno as the focus as Deno's development shifted towards being LLM heavy. Node now supporting permissions would likely be the priority now.
The vibecoded rewrite led to the deprecation of support for Bun but I believe Deno was already the default. Also Bun had the note “No permission restrictions available. Scripts have full file system and network access.”
There was a ton of criticism beyond "ai bad". A complete rewrite, in a different language, is a brand new project. It doesn't have any where near the hardening as the previous version thousands of deployments. If they had done that exact same thing but without AI people still would have been upset.
> 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".
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
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.
Node only has experimental permissions support (making it not as good for local scripts), and no WebGPU (though you can import dawn wrapper). Deno desktop is way ahead of anything available for Node.
Exactly that. I am really surprised by the amount of comments with this huge sentiment and doom mongering. These days it’s really not a big deal. Million lines of deno based ts is not a problem because pretty much any functionality provided to deno is available for node as well. You probably can migrate off much of the external deps without much hassle. You can even migrate to different language ecosystem altogether like others have mentioned in comments.
> ...pretty much any functionality provided to deno is available for node as well.
Unfortunately Node still can't do something like this out of the box (AFAIK at least):
import { Bla } from "npm:bla@^5";
Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.
Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.
Bun always seemed weird because they decided to build it with Zig. I want Zig to succeed, but it's not stable yet.
It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.
It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.
However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.
As a non-js developer, Bun compiles my ts code to local executables nicely. Allows me to experiment with the new diversity of ts frameworks and distribute the binaries (hobby scope).
I mean I used to do a lot of things I'm glad I don't have to anymore. I'm not a big fan of doing repetitive work just because I understand how to.
Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.
I also don't like repetitive work, but I think it can be beneficial to understand how the tools you use work, and bun/Deno seem to abstract much of it away.
Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.
What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.
For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.
However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.
> I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.
Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.
One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.
One should understand how their tools work but there's no such thing as doing that without understanding things across the abstractions involved and at least a good portion of what happens under them, Deno or not.
It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.
I lead a project built on Deno; it was not my call, just to be clear. Deno turned out unfortunately to be a miss and we had seen the writing on the wall. FWIW, we're moving to a much bigger Rust core program with node for JS user extensibility. (In other words, I'm not willing to risk using the deno_core crates.)
The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.
Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
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?
For me Deno has a really nice security posture, the permissions model is just something I haven't seen in from other runtimes (JS or otherwise). There were other nice features (native typescript support, compilation to a standalone binary), but the permissions model was just unique.
Like a decade ago I got into a huge fight with a Staff Eng at our company over Dart. I had just been put in charge of the company's architecture and one of the first things I did was migrate everything to TypeScript (which was relatively new at the time). He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).
> He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).
1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.
I don't know enough about Angular 2 to know exactly how much of a bad choice that was, but my experience in React has always been "they should have used something else". I vaguely recall our lead backend being unhappy with his decision to do the original admin panel in Angular, but I chalked that up to him not being a frontender.
For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.
It's really a bummer that Dart gets a bad rap, because of its early versions. The recent versions of Dart are a lovely language to work with. Pub is the only package manager I've used that approaches Cargo in quality.
All TypeScript competitors got out-engineered by Microsoft. It’s a triumph of experience over new ideas.
How well designed the initial versions of TypeScript were can be seen by how smoothly later versions were able to build on them, and even after so many major improvements the language has barely a wart (enums probably being the only one).
namespaces are the other one, and that's a fun legacy because Typescript had to implement a half dozen module systems in the early days: no modules (jQuery-era globalThis pollution), AMD, UMD, CommonJS, SystemJS, Typescript's own which was proto-ESM inspired but not ESM, then Typescript's realignment with ESM.
Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)
But it is Open Source, so if said companies like Deno enough, all they have to do is pay for its continued maintenance and development. This is one major thing that sets Open Source apart from proprietary software.
Given these two are both comparable to the Cloudflare developer stack that I often think of as alternatives, this makes the decision to let Deno die feel at least a bit more calculated.
I do wonder if it's been shopped around to any of these large-scale users as potential maintainers. Seems in the overall wheelhouse for Supabase in particular.
> 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?
Wait till you hear about this thing called Bun.
Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.
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.
> why? unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...why acquire and kill?
Aquihiring is a time-tested strategy to build out a team. The Deno folks likely have a bunch of experience that Cloudflare is well placed to make use of
> Unless you dangle HEFTY stock options with incremental maturity dates
That is indeed how this whole thing works. I used to work with several folks who were kicking around FAANG for 4 years till their acquisition stock fully vested
When you consider how much time/money it takes to hire an experienced engineer, and how quickly they are liable to jump to the competition, acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal
If the talent wanted to work at Cloudflair, they'd apply there. Being acquired is a loss of agency and the project you care about is shut down. Several public research papers say retention is hard.
Which also leads to considerable questions about if the thing being shut down in the acquirehire was the real purpose and any momentum of the team itself moving to new projects a bonus.
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.
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
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.
This is a weird strategy to stake future IP value on in the age of AI. With competent and fully qualified team, anyone should be able to reverse engineer this idea and build a roadmap for their own implementation. Especially in the world of open source.
1. They can gain at least a temporary advantage by using a proprietary version. They'll have the original devs who can continue where they were before.
2. I wouldn't be surprised if we end up with a situation where LLM-based copyright laundering becomes illegal/enforced, but only in favor of large corporations' copyright, in which case they could maintain the advantage
What would they miss out on? A bunch of PRslop? The "open source community" is now dead.
Do you really think someone off the street, armed with Opus 5.5 could recreate Deno? Or would you pull Cloudflare people off what they were doing (meaning it's a very inefficient company) to work on this?
At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.
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.
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).
Workers against Deno Deploy? And even if you don't count Deno as a whole in the same market as Cloudflare it's still shady as hell. They had plans to buy out a company with the explicit intent to shut down their main product.
You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.
What they pulled off instead is the most toxic form of acqui hire ever invented.
"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.
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.
Right up until the day the founder gets bored and leaves Anthropic, or some middle manager does a reorg and the project isn't important to them anymore.
Anthropic use bun. It wasn't an acquihire. They depend on the tool. If the founder gets bored and leaves, it will continue to exist at least as long as Anthropic use 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.
I doubt deno could have funded its development purely from sponsorship. And Deploy generated real revenue (on its OEM/b2b side).
Jt is interesting to speculate on what might have been had Deno never been a profit-seeking company. But having worked there, I am reasonably confident in my assessment above.
I only tangentially followed Deno, but am a proud Deno 1 hoodie-haver!
A compatibility shim sounds like a great community run project while the core team could work on the slow-but-steady w/o concerning the core with too much burden of node compat.
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
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.
> 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.
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?
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.
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's relative measurement. When you are 9th grader, even a freshman college student feels way older.
But as you are in your 30s, you feel less of difference.
Same thing here, How do you define Windows and Emacs being "old"? For those who's been using it for decades, not as old as Voyager software. For those who lived through those times, Windows and Emacs feels younger.
See where I am going with it?
---
If you have a nephew or a kid, they will say you are "old". But your parents will consider you "young" for the rest of their lives.
In the context of software, I think "how old is old" depends on how web based the software has been over its lifetime.
I think 8 years is old for software that has heavily Web based like Deno. But Windows and Emacs have had portions of their lifetime without the Web in a meaningful way, so 8 years would be young.
> "Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.
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
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)
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.
The majority of the last year's development has been via LLM. I don't think anyone is going to want to fork that when they can just tell an LLM to do whatever and get the same result
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'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.
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.
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.
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.
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.
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.
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.
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
> With Bun I think it was basically a marketing ploy.
I don't know, the vast majority of daily Microsoft Defender offenders I have to wade through, as well as the majority of the intune remidy requests are related to Node being used in various Microsoft applications. The Azure CLI is one of them, but the one which really ranks high on the security risk levels is always something "Agent" or "AI" related folder which I assume are what runs the Copilot and Cowork clients.
I think I had around 800 CVE warnings in relations to Axios in side a Microsoft tool related to AI running node this week, from just 8 devices.
Bun having it's own batteries included is probably a nice benefit to avoid that.
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’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...
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 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.
Yeah, after I posted I realized that Go remark was not correct, but again, I am confused how do you combine all that. JS I can read and understand (well, understand), I have seen it already, TS, I compile TS to JS right, and then I can choose any of the current available runtimes to run that code, correct? And final fat binary that is deployed has what, whatever runtime I choose to be?
Huh, I think I guessed that right, I do use such apps, but never bothered to understand how they are actually packed.
> Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code.
It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].
Yes, everything I have is pinned that way too. That's why I said "when it is done", even in my limited experience and contact with TS it is not currently a suitable replacement, and I'm not a particularly hard user of the tool chain. (I am having a hard time phrasing this in a way that I'm completely sure can't be potentially read as snarky or short-tempered, so I guess I'll just go with the clumsy direct statement that I'm agreeing with you and continuing the thought from my own experience, not trying to disagree.)
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
Well, that "Go crap" needs some explanation. The reason I am not involved in JS is because I mostly use Go for backend, and I am happy I have no relation with frontend at all. And even that is just small part of my job and what I do daily (Radius, Diameter, etc.).
But, I never heard about Go crap (in that context maybe), or experienced any crap there, it is just nice and simple. What are the issues?
Many of the "rewrite it in Rust/Go/whatever fad" projects that have cropped up have been done with the assistance of AI, especially because both languages are a pretty heavy divergence if you're used to C, C++, Java or JavaScript.
And when you can't manage to coordinate with an ecosystem dependency as large as webpack before the migration to make sure nothing breaks... my suspicion is utter incompetence and gross misuse of AI.
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
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.
While it may as well be the same thing, the Anthropic acquisition isn't what turned me off of Bun, it was the vibe-coded Rust refactor. As soon as that happened I dropped Bun. Deno was what I ended up more interested in (Deno Fresh seemed really cool too), but I guess it's just back to Node/PNPM for me now as well. What is going on anymore...
Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.
Bun is dead. It's a skin-walker wearing the appearance of its former self. They screwed the community when they got acquired.
Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.
> 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 throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.
Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.
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.
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 personally see it as valuable for similar reasons -- plus the ability to just import via web if a package is compatible with browsers, and it being open source and free for the community to fork and rebuild in case something like this goes south.
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.
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.
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
I mean, sure, but this doesn't preclude CF from keeping a few people around who can work on the runtime while everyone else does... whatever CF wants them to do.
They don't even need to be the long term stewards either. Spend some time setting up a proper governance structure for Deno, hand it off, and then pay some maintainers to continue their existing effort.
At least how it's stated in the post, it really feels like an "ah good luck everyone, I'm out!" sorta deal, which seriously sucks for everyone who really believed in Deno.
> 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.
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.
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.
I think it makes more sense to use the kernel‘s’s sandboxing utilities (like seccomp, SELinux, namespaces, prctl and eBPF) than to rely on the process to try to isolate itself purely in userspace which will always have holes.
> 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.
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".
It's sad how it worked out. Bun really stole Deno's momentum. Deno's foundational trust model really feels like its what the JS community needs. There were so many genuine improvements over Node that I don't think Node can ever just adopt
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.
This. Internally as of about two months ago I use _zero_ open source code in any of my projects. Anything that I was still relying on was 100% rewritten with an LLM. The only hard dependency remaining is the Linux kernel itself which I predict I'll be able to replace in a few months. The current rewrite is functional except for networking and wider driver support.
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.
It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.
I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are
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.
I agree it would be an awkward choice for an agent that runs as a local application, but the trend I think is towards agents running more and more on servers.
> 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.)
> 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.
Deno wasn't doing well and was repeatedly outperformed in downloads and raw performance when Bun was written in Zig, and even before Bun got acquired by Anthropic.
My point is, even if Bun stayed on Zig, Deno still struggled to compete regardless of the language used.
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.
No people on the Boards of both companies? Sorry for being cynical. Seen so much funny stuff in this industry. Good for Deno. Better choice given the talent behind it than Bun, IMHO.
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?
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...
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.
So unless someone else picks up development, Deno will no longer be supported.
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.
I'm vert bullish on AI, but vibe-porting the piece of software you're the main maintainer over a few weeks without letting anyone in the community know and pushing that as a fait accompli to both your userbase and your open source community is definitely the kind of behavior that makes you not trustworthy enough to depend on.
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
Unfortunately Node still can't do something like this out of the box (AFAIK at least):
Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.
There's no business here anymore.
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.)
It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.
It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.
For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.
So I never had much interest in looking into benefits of Deno or bun.
However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.
Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.
Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.
What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.
For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.
However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.
> I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.
It also gets messy if you're building 2 or 3 services simultaneously out of the same node_modules dir. E.g frontend, backend, shared, scripts...
Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.
One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.
It would be far from a standard solution though.
It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.
I don't. What do you mean?
The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
https://docs.deno.com/api/deno/
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
It's an acquihire. They hired the people behind Deno
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?
https://docs.deno.com/runtime/fundamentals/security/
https://nodejs.org/api/permissions.html - since v20 - Apr 17, 2023
https://nodejs.org/learn/typescript/run-natively - stable and without a flag since v22.18.0 - which sometime after Apr 24, 2024 which was the v22.0.0 release
https://nodejs.org/api/single-executable-applications.html - Added in: v19.7.0, v18.16.0 but still in Active Development (not stable yet) - 2022
For reference, Deno was released in 2020 with all of these features from the start.
Feels like it always take some healthy competition for Node to make big strides like this. Like the whole io.js fork thing a long while ago.
1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.
For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.
How well designed the initial versions of TypeScript were can be seen by how smoothly later versions were able to build on them, and even after so many major improvements the language has barely a wart (enums probably being the only one).
Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)
Hey, you jest, but Flutter has a lot of traction!
(I conceptually like Flutter, but I can't get over the Dart thing, so I'm not part of that traction.)
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
This is actually a good decision though.
Wait till you hear about this thing called Bun.
Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.
Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.
They should hire a few devs to develop it then.
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.
unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...
...why acquire and kill? cloudflare can have more outreach and reputation by keeping deno alive
Aquihiring is a time-tested strategy to build out a team. The Deno folks likely have a bunch of experience that Cloudflare is well placed to make use of
Unless you dangle HEFTY stock options with incremental maturity dates, nothing is else is keeping them from leaving.
That is indeed how this whole thing works. I used to work with several folks who were kicking around FAANG for 4 years till their acquisition stock fully vested
When you consider how much time/money it takes to hire an experienced engineer, and how quickly they are liable to jump to the competition, acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal
well... why not tie who's already inside the company (who you actually know about) instead of an external people (who you DON't know about)?
it's much difficult to get info about some external person, and most info is about external reputation ('the looks')
though... that's the reason job-ping-pongs work: someone outside looks better than someone inside, because of your lack of info
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
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.
This is a weird strategy to stake future IP value on in the age of AI. With competent and fully qualified team, anyone should be able to reverse engineer this idea and build a roadmap for their own implementation. Especially in the world of open source.
What would they miss out on? A bunch of PRslop? The "open source community" is now dead.
At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.
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.
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?
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 think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
IMHO, it shouldn't be allowed.
You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.
What they pulled off instead is the most toxic form of acqui hire ever invented.
"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.
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
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.
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.
Jt is interesting to speculate on what might have been had Deno never been a profit-seeking company. But having worked there, I am reasonably confident in my assessment above.
A compatibility shim sounds like a great community run project while the core team could work on the slow-but-steady w/o concerning the core with too much burden of node compat.
Deno is now a feedstock for future JS runtimes.
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
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.
> "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.
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
https://github.com/elyase/awesome-object-storage-native#stat...
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'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.
https://github.com/elyase/awesome-object-storage-native#stat...
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.
Things don’t always shake out as you plan
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's relative measurement. When you are 9th grader, even a freshman college student feels way older.
But as you are in your 30s, you feel less of difference.
Same thing here, How do you define Windows and Emacs being "old"? For those who's been using it for decades, not as old as Voyager software. For those who lived through those times, Windows and Emacs feels younger.
See where I am going with it?
---
If you have a nephew or a kid, they will say you are "old". But your parents will consider you "young" for the rest of their lives.
I think 8 years is old for software that has heavily Web based like Deno. But Windows and Emacs have had portions of their lifetime without the Web in a meaningful way, so 8 years would be young.
This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.
What would you consider legacy? (not trynna fight, just wondering what you consider as one)
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.
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.
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)
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?
1: https://peps.python.org/pep-0723/
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.
of course i’m only talking about deno, the technology not deno, the cloud service.
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.
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.
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
i always wondered how they were making money
I also wish they expanded jurisdiction more. I worked at companies that couldn't use Cloudflare because of specific location requirements in contracts
If they bought Neon that'd be a coup.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
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.
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.
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
No indication cloudflare would pursue that yet that I see.
[0] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno... [1] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno...
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
https://theoatmeal.com/comics/exposure
They took on VC funding.
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.
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
I don't know, the vast majority of daily Microsoft Defender offenders I have to wade through, as well as the majority of the intune remidy requests are related to Node being used in various Microsoft applications. The Azure CLI is one of them, but the one which really ranks high on the security risk levels is always something "Agent" or "AI" related folder which I assume are what runs the Copilot and Cowork clients.
I think I had around 800 CVE warnings in relations to Axios in side a Microsoft tool related to AI running node this week, from just 8 devices.
Bun having it's own batteries included is probably a nice benefit to avoid that.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
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 know Node is boring but it's not going anywhere.
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.
It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].
[1] https://github.com/TypeStrong/ts-loader/issues/1671
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
And when you can't manage to coordinate with an ecosystem dependency as large as webpack before the migration to make sure nothing breaks... my suspicion is utter incompetence and gross misuse of AI.
Deno was never going to be a thing anyways.
Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.
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.
Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.
For example it doesn't support enums.
Bun and Deno do the real thing.
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?
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 know the runtime is in trouble, but i'm not as worried tbh b/c the principles deno championed are going to keep going.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
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.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
CF workerd is only one out of those 5.
They don't even need to be the long term stewards either. Spend some time setting up a proper governance structure for Deno, hand it off, and then pay some maintainers to continue their existing effort.
At least how it's stated in the post, it really feels like an "ah good luck everyone, I'm out!" sorta deal, which seriously sucks for everyone who really believed in Deno.
Extremely disappointing...
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/
I think they ran out of money and joining Cloudflare was their only remaining option.
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.
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
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.
> 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.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
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.
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.
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.
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.
I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are
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.
https://blog.cloudflare.com/code-mode/
Given it's server focus though, I'd be very surprised if it was as good as Deno for giving agents a local code sandbox.
Also another blog post from when the feature became generally available: https://blog.cloudflare.com/dynamic-workers/
I agree it would be an awkward choice for an agent that runs as a local application, but the trend I think is towards agents running more and more on servers.
> 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 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.
My point is, even if Bun stayed on Zig, Deno still struggled to compete regardless of the language used.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
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.
[0] https://www.sec.gov/Archives/edgar/data/1477333/000119312519...
Okay, but I never said there was, so nice strawman argument
At this point they are already up 1000% on their investment
They would rather have Deno pursue an acquisition instead of shutting down and losing their investment.
The only questionable detail about this announcement is it was for an undisclosed amount. Make of that what you will.
I mean that's just not how it works, most VC investments go to zero and they know that.
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.
Uh no. The lack of users killed Deno.
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.