> 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.
bodge5000 2 minutes ago [-]
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
binlog 2 hours ago [-]
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.
coldtea 1 hours ago [-]
>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?
jamesrr39 8 minutes ago [-]
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).
ZeroCool2u 8 minutes ago [-]
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.
sysguest 1 hours ago [-]
well Deno was the only player who could have prevented recent npm security disasters:
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
maherbeg 1 hours ago [-]
Slack? I think some of their plugins API was all Deno based for a while.
chaosharmonic 1 hours ago [-]
Netlify and Supabase have also been using them for edge functions.
0x6c6f6c 53 minutes ago [-]
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.
vmg12 1 hours ago [-]
> Do they also do their front-end in Dart?
This is actually a good decision though.
Onavo 50 minutes ago [-]
> 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.
redox99 1 hours ago [-]
You can migrate off deno in a single day. It's not a big deal.
matesz 47 minutes ago [-]
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.
flohofwoe 4 minutes ago [-]
> ...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.
Deno also has a builtin type checker, linter, formatter and package manager. In node these are all separate (and often 3rd-party) tools.
echelon 7 minutes ago [-]
And this is why deno is exiting.
There's no business here anymore.
hodder 1 hours ago [-]
Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.
fg137 1 hours ago [-]
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.)
sionisrecur 52 minutes ago [-]
As long as the competition forced Node to become better then it's all good.
jimbokun 16 minutes ago [-]
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.
not-kinsale-joe 23 minutes ago [-]
I wonder how much they have financially contributed to Deno.
elcritch 2 hours ago [-]
How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.
cscheid 1 hours ago [-]
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.
daveidol 44 minutes ago [-]
Can you elaborate on why it was a “miss”?
gritzko 1 hours ago [-]
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.
kuekacang 2 hours ago [-]
I went all-in with bun. Did I bet wrong?
Buttons840 1 hours ago [-]
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.
Bun was converted fully into Rust overnight, works fine so far.
1 hours ago [-]
croes 1 hours ago [-]
Didn’t they switch to Rust?
user43928 2 hours ago [-]
What did it get you?
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.
nateb2022 2 hours ago [-]
As a former bun user, speed.
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.
threecheese 47 minutes ago [-]
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).
zamadatix 1 hours ago [-]
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.
user43928 42 minutes ago [-]
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.
KronisLV 22 minutes ago [-]
Silly drive by take:
> 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.
behnamoh 2 hours ago [-]
Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.
buremba 2 hours ago [-]
Use bun when it's drop in replacement of npm, never use Bun API itself.
simonw 2 hours ago [-]
"we know the extents they go to protect their competitive advantage"
I don't. What do you mean?
trio8453 1 hours ago [-]
Asking as a non-JS person - what's the cost and effort to switch?
jayknight 40 minutes ago [-]
It probably depends on how much of the deno-specific api is being used, and then how similar that is to whatever you're going to switch to.
Honestly migrating back is trivial now. It just isn't that big of a pain.
clint 32 minutes ago [-]
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.
conartist6 44 minutes ago [-]
It's why I usually look more closely at the comments here than at the story for stories like this.
2OEH8eoCRo0 1 hours ago [-]
> So many companies went all-in on Deno in recent years.
They should hire a few devs to develop it then.
porridgeraisin 2 hours ago [-]
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.
vazark 2 hours ago [-]
The way i see it, cloudflare acquired celld. Deno was just given a decent burial as part of the package
troupo 2 hours ago [-]
> I was really surprised that cloudflare was acquiring deno to be honest
It's an acquihire. They hired the people behind Deno
59 minutes ago [-]
simonw 2 hours 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!
rancar2 1 hours 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.
elcritch 2 hours ago [-]
Definitely negative karma points for Cloudflare.
sysguest 1 hours ago [-]
well I just don't get it -- why?
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
swiftcoder 57 minutes ago [-]
> 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
ptaffs 23 minutes ago [-]
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.
moistoreos 29 minutes ago [-]
Aquihiring also requires the personnel hired to... actually stay with the company....
Unless you dangle HEFTY stock options with incremental maturity dates, nothing is else is keeping them from leaving.
benrutter 30 minutes ago [-]
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?
thayne 12 minutes ago [-]
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.
taikon 49 minutes ago [-]
Why would they acquire them then shut it down? Is there a reason for that?
ttul 28 minutes ago [-]
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.
arnvald 33 minutes ago [-]
Acquihire - they’re acquiring it for the team behind it to eventually develop proprietary software
moistoreos 24 minutes ago [-]
> develop proprietary software
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.
"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.
edf13 2 hours ago [-]
This is the real headline... and more so that it has been hidden away.
ericfr11 22 minutes ago [-]
Interesting. I guess open source is not as dependable as it used to be
yoyohello13 1 hours ago [-]
Damn that sucks. I love Deno. It really should have ‘won’ the runtime race. Oh well.
2 hours ago [-]
nchmy 2 hours ago [-]
I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.
hackerbrother 1 hours ago [-]
Shame- it is my favorite Markdown formatter.
giancarlostoro 2 hours ago [-]
Thats really upsetting ngl.
sebmellen 2 hours ago [-]
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.
moralestapia 2 hours ago [-]
Hmm ... so why would they acquire it to let it die?
yxhuvud 2 hours ago [-]
Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.
corytheboyd 2 hours ago [-]
Competitors use it as their serverless JS runtime, likely as simple as that.
ffsm8 2 hours ago [-]
Isn't that underselling the opportunity?
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
2 hours ago [-]
rvz 2 hours ago [-]
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.
binlog 2 hours ago [-]
Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.
kaliqt 1 hours ago [-]
Bun being acquired was not an admission of defeat. They are still actively developing.
pylotlight 2 hours ago [-]
[flagged]
binlog 2 hours ago [-]
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.
famouswaffles 17 minutes ago [-]
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.
freeopinion 2 hours ago [-]
Didn't the danger of the founder getting bored always exist? With or without Anthropic?
binlog 2 hours ago [-]
What happens when the founder of node.js walks away? Nothing, because the project is community driven and is backed by the Linux foundation.
simonw 2 hours ago [-]
Good example there, since Ryan Dahl of Deno is the founder of node.js.
cjonas 2 hours ago [-]
[flagged]
niek_pas 2 hours ago [-]
The word 'skitzo' is pretty offensive to people who actually suffer from schizophrenia, maybe try 'unhinged' or 'bizarre' or something.
tommica 2 hours ago [-]
[flagged]
Forgeties79 2 hours ago [-]
[flagged]
k33n 2 hours ago [-]
[flagged]
tommica 2 hours ago [-]
[flagged]
k33n 2 hours ago [-]
[flagged]
williamdclt 2 hours ago [-]
[flagged]
pylotlight 2 hours ago [-]
[flagged]
Forgeties79 2 hours ago [-]
[flagged]
diroussel 2 hours ago [-]
Anthropic bought bun.sh
diroussel 2 hours ago [-]
Interestingly, Jared Sumner of bun fame is the anthropic guy who pushed claud to find this new limit in the Rieman hypothesis.
2 hours ago [-]
MeetingsBrowser 2 hours ago [-]
Anthropic acquired bun
FrostKiwi 2 hours ago [-]
That was bun, not deno
2 hours ago [-]
2 hours ago [-]
2 hours ago [-]
2 hours ago [-]
behnamoh 2 hours ago [-]
Kinda feels like a rug pull, similar to Bun.
kaliqt 1 hours ago [-]
Not even close as Bun is still being actively developed, albeit with less fervor.
57 minutes ago [-]
singpolyma3 2 hours ago [-]
Which any existing user can just do?
coldtea 1 hours ago [-]
"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.
networked 58 minutes ago [-]
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.
k9294 40 minutes ago [-]
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.
barkerja 26 minutes ago [-]
> 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 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.
TheRoque 1 hours ago [-]
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 ask alternative. In the age of the LLMs, if you wanna get out of Node, you better translate all to native Go or Rust.
kaoD 44 minutes ago [-]
8 years is not super old, or even old. It's important to understand software maturity cycles for core components.
yipinwong 34 minutes ago [-]
"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.
hbn 14 minutes ago [-]
If 8 years is "super old" in terms of software, what is Windows? Or Emacs? Or old Fortran software from the 50s in the Voyager software?
SenHeng 17 minutes ago [-]
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.
hbn 13 minutes ago [-]
Also it didn't hit 1.0 until 2020 so it's more accurate to say it's 6 years old.
TheRoque 32 minutes ago [-]
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
goosejuice 42 minutes ago [-]
> 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.
bennett_dev 2 hours ago [-]
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.
TIPSIO 1 hours ago [-]
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
timdorr 2 hours ago [-]
Investors are a helluva drug
mapmeld 1 hours ago [-]
Yeah they just made me migrate my blog to their new cloud platform four months ago.
vanviegen 2 hours ago [-]
Meh, those types of large scale migrations are just a very short prompt nowadays.
phaser 2 hours ago [-]
specially deno to bun
ryanrasti 2 hours ago [-]
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.
OtherShrezzing 1 hours ago [-]
>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.
flohofwoe 1 hours ago [-]
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?
ewy1 33 minutes ago [-]
if you're not locked to javascript you could use python with pep-723[1] to declare inline dependencies
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.
phaser 2 hours ago [-]
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.
pimterry 2 hours ago [-]
> 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.
mzajc 2 hours ago [-]
> 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.
weli 2 hours ago [-]
read the blogpost, they are discontinuing deno after 1 year
adobrawy 1 hours ago [-]
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.
phaser 2 hours ago [-]
it’s open source. i’m hoping it gets picked up by the community. maybe i’m just too hopeful
its-summertime 6 minutes ago [-]
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.
bicepjai 23 minutes ago [-]
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.
culi 17 minutes ago [-]
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
hbn 5 minutes ago [-]
I think in a case like Bun they're also potentially buying the pre-built goodwill associated with the project.
mattvr 17 minutes ago [-]
In this case, they're explicitly not buying the runtime. They're killing the runtime.
tiborsaas 2 hours ago [-]
Congrats on the exit :)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
bsoqk 2 hours ago [-]
And then Danone.
khalidkhair 2 hours ago [-]
This one might have to be spooned
nateb2022 2 hours ago [-]
Sounds like something Bending Spoons would like
culi 8 minutes ago [-]
Can't believe they bought out Vite and now Deno. All our toolchains are getting bought out by military contractors
afavour 17 minutes ago [-]
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.
6thbit 24 minutes ago [-]
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.
aravindputrevu 24 minutes ago [-]
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.
afavour 3 minutes ago [-]
> What's happening to JS platforms?
They took on VC funding.
SenHeng 12 minutes ago [-]
People need to eat and pay rent. Can’t survive on just goodwill.
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
shados 2 hours ago [-]
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
CuriouslyC 1 hours ago [-]
D1 is a very different product. D1 is designed to be tenant sharded for any real workloads.
If they bought Neon that'd be a coup.
eknkc 2 hours ago [-]
Yeah. D1 is nice and easy but a serverless postgres offering would make a significant difference.
HatchedLake721 41 minutes ago [-]
Planetscale?
po1nt 2 hours ago [-]
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.
adamddev1 2 hours ago [-]
What did you transition to?
schnebbau 48 minutes ago [-]
AI.
multisport 2 hours ago [-]
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.
DannyBee 55 minutes ago [-]
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.
vmg12 2 hours ago [-]
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
I'm really happy to hear this. Congrats to everyone involved.
ForHackernews 2 hours ago [-]
Sounds like the opposite: They are killing Deno to work on celld
sandelz 1 hours ago [-]
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.
huqedato 1 hours ago [-]
RIP Deno. Goes into the bin, after Bun.
bluegatty 22 minutes ago [-]
Wow. Just about to choose Deno for something. That not only makes me rethink Deno but ... rethink a lot of things ...
mattvr 18 minutes ago [-]
Inevitable for a project like this when you take VC money, unfortunately.
JaceComix 2 hours ago [-]
Node always felt so annoying to deal with. I was really excited when Bun and Deno were coming up. Pour one out.
ravenstine 44 minutes ago [-]
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.
randall 26 minutes ago [-]
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.
danw1979 23 minutes ago [-]
What ? They are literally stopping development in a year.
culi 16 minutes ago [-]
You think the open source community will be able to continue deno? Did you miss the part where they're stopping development on it?
hoppp 23 minutes ago [-]
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.
chaosharmonic 1 hours ago [-]
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?
agp2572 54 minutes ago [-]
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.
gen2brain 2 hours ago [-]
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?
n_e 2 hours ago [-]
> 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.
sensanaty 1 hours ago [-]
There's basically no reason not to just go with Node as 99% of projects out there do
croes 1 hours ago [-]
Isn’t the whole node npm ecosystem now with AI a greater risk as before?
thunderfork 13 minutes ago [-]
"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)
jerf 2 hours ago [-]
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.
gen2brain 1 hours ago [-]
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.
mschuster91 1 hours ago [-]
> 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.
gen2brain 56 minutes ago [-]
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?
mschuster91 46 minutes ago [-]
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.
CrimsonRain 2 hours ago [-]
There's just one worthy of using for fresh project: Bun.
Deno was never going to be a thing anyways.
SkyeCA 2 hours ago [-]
Just use Node. Community led and supported by the Linux Foundation.
righthand 2 hours ago [-]
Why not the standard NodeJS? Well supported and not heavily influenced by acquisition or trends like bun is?
CuriouslyC 1 hours ago [-]
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.
alexfortin 24 minutes ago [-]
More or less the same but I dropped Bun after Anthropic acquisition so I now default to PNPM and Vitest, which is ok.
mschuster91 1 hours ago [-]
> 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.
nozzlegear 2 hours ago [-]
I'd just go with Node, it supports TS natively now.
bel8 1 hours ago [-]
NodeJS just strips TS types and prays that it runs as JS. It's not a native support by any means.
For example it doesn't support enums.
Bun and Deno do the real thing.
crsv 41 minutes ago [-]
Grats on the bag.
dzonga 1 hours ago [-]
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.
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
gxcsoccer 39 minutes ago [-]
Cloudflare is playing a big game ...
dpc94 47 minutes ago [-]
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.
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.
mbStavola 2 hours ago [-]
No idea why CF wouldn't just have them to continue working on Deno indefinitely...
brachkow 2 hours ago [-]
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
notnullorvoid 55 minutes ago [-]
Deno is a excellent and quirky severless, server, CLI, library, and GUI technology.
CF workerd is only one out of those 5.
mbStavola 2 hours ago [-]
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.
notnullorvoid 2 hours ago [-]
> 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...
zmj 1 hours ago [-]
This is awesome. The Cloudflare platform is great; being able to run more of it locally is a definite plus.
> 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.
1 hours ago [-]
HeadOfProbing 2 hours ago [-]
Deno was a good idea in the Old World of software development before LLMs, and simply doesn’t make sense anymore.
oblio 2 hours ago [-]
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.
Pesthuf 2 hours ago [-]
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.
hollowturtle 2 hours ago [-]
I warn you to not try to argue with ai shilling people
2 hours ago [-]
2 hours ago [-]
asgr 1 hours ago [-]
</3
its-summertime 2 hours ago [-]
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.
asar 2 hours ago [-]
really wondering what role celld played in the negotiations
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".
hoppp 21 minutes ago [-]
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.
culi 10 minutes ago [-]
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
nullstyle 14 minutes ago [-]
What a shame. Guess me and the clankers will be maintaining a fork now
Jgrubb 2 hours ago [-]
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.
oblio 2 hours ago [-]
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.
vachina 1 hours ago [-]
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.
rfgplk 44 minutes ago [-]
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.
classified 2 hours ago [-]
R.I.P.
kentonv 2 hours ago [-]
Please be sure to read the post on Cloudflare's blog, it's not just fluff:
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.
patcon 2 hours ago [-]
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.
mark_and_sweep 2 hours ago [-]
Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?
> 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
smt88 2 hours ago [-]
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.
evbogue 2 hours ago [-]
Congrats Ry
victorbjorklund 2 hours ago [-]
RIP
ramesh31 2 hours ago [-]
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.
cyanydeez 2 hours ago [-]
is this Cloudflare signalling they're going to hard pivot to being an AI company?
notnullorvoid 2 hours ago [-]
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.
kentonv 2 hours ago [-]
workerd has also had granular sandboxing all along... I actually coined the term "code mode" in this blog post:
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.
cyanydeez 1 hours ago [-]
hard pivot to ai confirmed.
kentonv 11 minutes ago [-]
I think it's well-known that we've been pretty focused on AI agent infrastructure for a while...
sharktheone 2 hours ago [-]
sorry, but who even is still working on Deno? All my friends who used to work on Deno got fired
wosined 2 hours ago [-]
> Deno sells out
cmrdporcupine 1 hours ago [-]
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.)
rfgplk 47 minutes ago [-]
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.
rvz 2 hours ago [-]
> 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.
vollbrecht 2 hours ago [-]
Isn't bun also written in rust, so can you clarify what your point is here?
rvz 2 hours ago [-]
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.
tommica 2 hours ago [-]
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.
oh_ok_lol 2 hours ago [-]
And all the VCs funding both companies celebrated the circular economy!
weird-eye-issue 2 hours ago [-]
Cloudflare is a publicly traded company.
officialchicken 2 hours ago [-]
There is nothing that requires a VC to sell part or all of their shares when an IPO occurs. And you can read their S1[0] to verify.
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.
rvz 2 hours ago [-]
...And the VCs who invested in Deno will be getting their return from Cloudflare acquiring it, since they are "not allowed to lose".
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.
weird-eye-issue 1 hours ago [-]
> not allowed to lose
I mean that's just not how it works, most VC investments go to zero and they know that.
oh_ok_lol 2 hours ago [-]
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?
massimodeluisa 22 minutes ago [-]
[flagged]
2 hours ago [-]
grougnax 1 hours ago [-]
[dead]
2 hours ago [-]
4729738210 1 hours ago [-]
I will be avoiding Deno.
rattray 2 hours ago [-]
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...
culi 22 minutes ago [-]
Welp. All tech eventually gets bought out by military contractors or grows big enough to become one.
Rendered at 15:39:59 GMT+0000 (Coordinated Universal Time) with Vercel.
So unless someone else picks up development, Deno will no longer be supported.
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/
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.
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.Deno also has a builtin type checker, linter, formatter and package manager. 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.)
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.
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.
I don't. What do you mean?
https://docs.deno.com/api/deno/
They should hire a few devs to develop it then.
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
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.
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?
IMHO, it shouldn't be allowed.
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.
"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.
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.
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
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.
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.
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.
Things don’t always shake out as you plan
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.
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.
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/
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.
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.
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
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
I know Node is boring but it's not going anywhere.
No indication cloudflare would pursue that yet that I see.
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
They took on VC funding.
https://theoatmeal.com/comics/exposure
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.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
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.
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 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?
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.
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.
For example it doesn't support enums.
Bun and Deno do the real thing.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
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/
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...
> 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.
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.
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.
> 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.
[0] https://www.sec.gov/Archives/edgar/data/1477333/000119312519...
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.