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.
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.
Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?
Maybe helpful context: https://x.com/rough__sea/status/2105853283617440032
> 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
It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
You still need a runtime for your CLIs though. How does local development work for celld and workerd? Are you moving back to Node for that?
Why let it get sucked into the gravity well of node compatibility then? How can the community carry it forward without you? Will CloudFlare release the name/assets, or it will have to be forked?
FWIW I think the project is likely highly maintainable with relatively small economic commitment. I would be willing to contribute. If anyone wants to discuss how we keep it going past the next year, please let me know.
Thanks for your response, ry. It's hard to put into words how much I appreciate your work, both on Node and Deno. Honestly, you saved me from a career as a Java dev. :) I've been using Node since 2013 and Deno since 2018 (when it was still written in Go)... I used both first for hobby projects and scripting and later, when they matured, also at work.
I disagree that there's little differentiation between Node and Deno these days. Sure, I love Deno's UX and tooling, but the security benefits Deno has over Node are still the number one reason, we're picking Deno over Node at work. I'm honestly sad we may have to reconsider and switch.
I understand you are working on a new model for server development and I'll take a look at celld for sure. But what about scripts? I have a couple hundred repositories all using Deno for a wide range of scripting tasks. I'd love to continue using Deno for scripting for another 8 years or longer.
I'm just feeling a bit sad, you know. It kinda feels like I'm gonna lose a friend. That happy little dinosaur, now standing in the pouring rain again...
...well, who decided to embrace Node compatibility?!
The DX of Deno far surpasses Node (or at least it did, idk if Node has caught up in that regard).
What are the big problems you see that still need solving that a future Deno (fork) could handle?
EDIT: Talking to people in the Discord and was reminded that the community may have been the inspiration. Adoption was low so boom, add Node compatibility and now adoption grows. MEH.
If I'm doing a fork, I'm removing Node.
To be fair, Deno and Bun's enhancements seemed to do a lot to set a fire under Node and have it implement various things it didn't have when both projects launched. This is a good thing.
Update, I'm doing a fork: https://ende.sh
I don't often post on the orange website. But this news was enough to make me want to say congratulations, friend.
Looking back now after almost 20 years (Nov 2009 to now for me), I can see the arc from what node was then to what celld can be now as your thinking has evolved
A distributed operating system running in userspace is the primitive that can break apart the siloing that has become the default across the walled gardens we all operate in
All the best in what's to come