> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.
>So many companies went all-in on Deno in recent years.
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
I 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.
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.
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 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.
Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.
I 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.
This might not be seen in much favourable light by many but IMO Cloudflare has the most elegant serveless PaaS as I have seen to date.
The design and architecture is extremely minimal to the point that all of it can be explained on a single A4 page with a 14pt font including D1 + Durable objects. And I hope that it stays that way.
It has all the primitives that you can wish for to build a software system on top of it be it queues, long running jobs, workflows, pipelines, email handlers, cron jobs and even built in AI models ready for you to be invoked.
ATM - it is extremely cheap, reliable, simpler and more capable than anything out there. Deno itself had very little scope anyway because almost no developer tooling is sellable in this environment even more so post AI. Therefore, it is going to accelerate the Cloudflare platform to be the best in class and hopefully not complex and bloated.
I’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.
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?
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.
>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.
Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.
I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless
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.
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.
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.
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.
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.
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 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.
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".
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.
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?
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
I'd guess Deno failed because of the original decision of not supporting node_modules, instead went with a different way of handling dependencies. Else the native typescript support would most likely had pushed them to bigger success past nodejs.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
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.
> 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.)
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.
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.
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...
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.
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.)
>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?
Slack? I think some of their plugins API was all Deno based for a while.
> Do they also do their front-end in Dart?
This is actually a good decision though.
How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.
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.
I went all-in with bun. Did I bet wrong?
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.
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.
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.
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.
Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.
Use bun when it's drop in replacement of npm, never use Bun API itself.
"we know the extents they go to protect their competitive advantage"
I don't. What do you mean?
> So many companies went all-in on Deno in recent years.
They should hire a few devs to develop it then.
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.
The way i see it, cloudflare acquired celld. Deno was just given a decent burial as part of the package
> I was really surprised that cloudflare was acquiring deno to be honest
It's an acquihire. They hired the people behind Deno
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!
Definitely negative karma points for Cloudflare.
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
This is the real headline... and more so that it has been hidden away.
I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.
Thats really upsetting ngl.
Which any existing user can just do?
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.
Kinda feels like a rug pull, similar to Bun.
Hmm ... so why would they acquire it to let it die?
Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.
Competitors use it as their serverless JS runtime, likely as simple as that.
Isn't that underselling the opportunity?
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
I mean we already have a winner (Bun) and it just means that Deno has admitted defeat.
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.
I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively. Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now.
Don’t have a strong opinion on any of this, but it’s actually super normal for anyone who helps run a business to push hard and try to grow it.
Things don’t always shake out as you plan
Yeah they just made me migrate my blog to their new cloud platform four months ago.
Investors are a helluva drug
Meh, those types of large scale migrations are just a very short prompt nowadays.
specially deno to bun
"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.
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.
The Cloudflare side is also worth a read: https://blog.cloudflare.com/deno-joins-cloudflare/
I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.
of course i’m only talking about deno, the technology not deno, the cloud service.
> I’m happy if this means Deno is able to get a second impulse
Bad news, sorry, the article says:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Sounds like Celld will live on within workerd, Deno is over.
> I’m happy if this means Deno is able to get a second impulse.
From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
read the blogpost, they are discontinuing deno after 1 year
The fact that Deno development is being suspended doesn't mean the community can't step in. The Deno runtime is licensed under MIT. Such forks might be impulse to grow even further.
it’s open source. i’m hoping it gets picked up by the community. maybe i’m just too hopeful
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?
Congrats on the exit :)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
And then Danone.
This one might have to be spooned
Sounds like something Bending Spoons would like
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.
>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.
Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.
I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless
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
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.
Yeah. D1 is nice and easy but a serverless postgres offering would make a significant difference.
If this was done to kill celld as a runtime that would be unfortunate.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
On the contrary. Please read my part of Cloudflare's blog post here: https://blog.cloudflare.com/deno-joins-cloudflare/
I'm really happy to hear this. Congrats to everyone involved.
Sounds like the opposite: They are killing Deno to work on celld
I was rooting for Deno so much as I was fighting with node for years. Luckily I made full transition from JS last year and not comming back.
What did you transition to?
my recent comment [0]: was deno was the only other tech player building a proper serverless platform to bring Cloudflare workers in an open source manner.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
the CF blog post suggests that is what the Deno team will be working on: combining workerd and celld for true self hostable workers/DOs
This is awesome. The Cloudflare platform is great; being able to run more of it locally is a definite plus.
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?
There's basically no reason not to just go with Node as 99% of projects out there do
> 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.
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.
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.
There's just one worthy of using for fresh project: Bun.
Deno was never going to be a thing anyways.
Just use Node. Community led and supported by the Linux Foundation.
Why not the standard NodeJS? Well supported and not heavily influenced by acquisition or trends like bun is?
I'd just go with Node, it supports TS natively now.
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.
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.
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.
It's only OpenAI which doesn't have an in-house modern runtime
They should just go all in with Wasm.
Can we rename title to "Deno is winding down" ? It's not joining cloudflare. the people are
Node always felt so annoying to deal with. I was really excited when Bun and Deno were coming up. Pour one out.
No idea why CF wouldn't just have them to continue working on Deno indefinitely...
Because Deno turned into some quirky serverless technology.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
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.
Extremely disappointing...
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".
really wondering what role celld played in the negotiations
From CloudFlare's side (https://blog.cloudflare.com/deno-joins-cloudflare/) is seems celld was the main point of this - letting the Deno team focus on making workerd self-hosting easier.
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.
R.I.P.
Congrats Ry
RIP
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.
sorry, but who even is still working on Deno? All my friends who used to work on Deno got fired
is this Cloudflare signalling they're going to hard pivot to being an AI company?
No if that were true they wouldn't be stopping development of Deno, which as it stands sits in the best position for codemode given it's granular sandboxing.
workerd has also had granular sandboxing all along... I actually coined the term "code mode" in this blog post:
https://blog.cloudflare.com/code-mode/
Kind of hard to figure out what sandboxing controls are available given the lack of docs.
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.
hard pivot to ai confirmed.
And all the VCs funding both companies celebrated the circular economy!
Cloudflare is a publicly traded company.
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.
[0] https://www.sec.gov/Archives/edgar/data/1477333/000119312519...
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.
...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.
> not allowed to lose
I mean that's just not how it works, most VC investments go to zero and they know that.
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?
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
I'd guess Deno failed because of the original decision of not supporting node_modules, instead went with a different way of handling dependencies. Else the native typescript support would most likely had pushed them to bigger success past nodejs.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
Isn't bun also written in rust, so can you clarify what your point is here?
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.
> Deno sells out
I read it more as:
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
Please be sure to read the post on Cloudflare's blog, it's not just fluff:
https://blog.cloudflare.com/deno-joins-cloudflare/
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
I do appreciate that it's not explicitly anti-competitive, but as a biochemist who spent a lot of time thinking about living systems, I am a bit concerned about a budding ecology that has perhaps collapsed <3
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?
I don’t know that many people reading this particular thread care whether this is a good business decision for Cloudflare.
Most of us are here because we’re curious what it means for Deno specifically and FOSS TypeScript runtimes in general, since Bun was also acquired.
I will be avoiding Deno.
Deno was a good idea in the Old World of software development before LLMs, and simply doesn’t make sense anymore.
Why? We probably need more sandboxing, not less.
Especially with LLMs automating all sorts of code and operational aspects, we could do Tcl/Lua type whitelist sandboxes where the application can only call a limited set of functions.
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.
I warn you to not try to argue with ai shilling people
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...