Kenton Varda posted: [...] And Ryan Dahl posted on Deno blog post: So, looks like the choices for people using the Deno runtime will be migrating to Node.js, migrating to workerd, or perhaps...
Kenton Varda posted:
In the interest of transparency, I do have to admit that workerd has always had one big gap in its production-readiness: Durable Objects. Workerd implements them, but only in a single-instance way, good enough for local testing, but unable to scale. We have always wanted to fix this. There are TODO comments in the code going back to the original release. The problem is, our production implementation of Durable Object routing is simply not the implementation any self-hoster would want. It's a beast, designed to handle hundreds of locations, with numerous dependencies on external services operated by a team of site reliability engineers. We knew we needed something different for the self-hosting use case, but we never quite found the time to build it. (I actually made an attempt last spring, but, embarrassingly, it didn't work.)
So now, hopefully, it's clear why we were happy about celld: Here was an implementation of Workers and Durable Objects designed to be fully compatible with our own, while being focused on being self-hostable and scalable. That's what we'd wanted to build for a while, and Deno Land was building it for us!
[...]
Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd. I'm incredibly excited for this work — I will personally be using it to host an instance of Cloudflare OS in my home.
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.
Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers.
JSR will continue operating, with its infrastructure moving to Cloudflare.
We will continue supporting rusty_v8 and work toward integrating it into workerd.
So, looks like the choices for people using the Deno runtime will be migrating to Node.js, migrating to workerd, or perhaps sticking with Deno, provided that there are enough users who decide that they want to stick with it that it continues as a standalone open source project.
(When does a open source project require a corporate sponsor?)
To answer your parenthetical, in my experience an open source project usually... well, I don't know if they NEED their corporate sponsor but they often acquire it under one of a few conditions:...
To answer your parenthetical, in my experience an open source project usually... well, I don't know if they NEED their corporate sponsor but they often acquire it under one of a few conditions:
The creator (or creative team) wants to work on the project full-time and sought out a business that can pay enough to essentially soft-acquire the project
The corporation has come to rely very heavily on the project and need a closed-source version or favored-partner status that allows them to either get the earliest features, exclusive support, and either early access to features or a pipeline to help shape ongoing versions of the project
The corporation needs to vent some money to get a tax break and the non-profit at the heart of the open source project is a good donation pathway
The corporation needs some PR recovery and donating to a popular platform deep in their milieu can help to rehabilitate their image
That's the things I can think of off the top of my head that I've seen happen out there. Mostly that's been my experience with the Mozilla Foundation and the Blender Foundation.
I think it's a shame that development on Deno is being shut down, but to be honest I don't know what kind of company (I mention companies because that's where the big sponsorships come from) would...
I think it's a shame that development on Deno is being shut down, but to be honest I don't know what kind of company (I mention companies because that's where the big sponsorships come from) would ever have used Deno as their JS runtime over Node. Node is more established, has a larger ecosystem of tools around it, and has clear management structure and funding for that provided through the OpenJS foundation. Having a series of standard library packages is neat (though Node had its own too, I guess), having a permissions model is great (Node now has one, opt-in), creating another public NPM registry is... a choice? But if I were the one deciding the technology stack for a company, I would be looking at which option is likely to be supported for a long time. That was never going to be Deno.
Anyone who chose Deno just learned they've got a year's worth of patches and security updates left. Anyone using Deno Deploy just learned they've got 6 months to move to CloudFlare or completely change their deployment. At least JSR is sticking around, but I get the feeling it'll be on life support more than active development. It's better than Deno just going completely under, I guess.
As an aside, I wonder what's going to happen to the lawsuit that Deno has against Oracle over the name JavaScript. They were asking for 200k in crowdfunding for discovery and received 44k. Will CloudFlare keep it going, or will they just quietly close it down and let Oracle still sit on the name? I also wonder if the legal costs contributed to Deno needing to be bought.
Kenton Varda posted:
[...]
And Ryan Dahl posted on Deno blog post:
So, looks like the choices for people using the Deno runtime will be migrating to Node.js, migrating to workerd, or perhaps sticking with Deno, provided that there are enough users who decide that they want to stick with it that it continues as a standalone open source project.
(When does a open source project require a corporate sponsor?)
To answer your parenthetical, in my experience an open source project usually... well, I don't know if they NEED their corporate sponsor but they often acquire it under one of a few conditions:
That's the things I can think of off the top of my head that I've seen happen out there. Mostly that's been my experience with the Mozilla Foundation and the Blender Foundation.
I think it's a shame that development on Deno is being shut down, but to be honest I don't know what kind of company (I mention companies because that's where the big sponsorships come from) would ever have used Deno as their JS runtime over Node. Node is more established, has a larger ecosystem of tools around it, and has clear management structure and funding for that provided through the OpenJS foundation. Having a series of standard library packages is neat (though Node had its own too, I guess), having a permissions model is great (Node now has one, opt-in), creating another public NPM registry is... a choice? But if I were the one deciding the technology stack for a company, I would be looking at which option is likely to be supported for a long time. That was never going to be Deno.
Anyone who chose Deno just learned they've got a year's worth of patches and security updates left. Anyone using Deno Deploy just learned they've got 6 months to move to CloudFlare or completely change their deployment. At least JSR is sticking around, but I get the feeling it'll be on life support more than active development. It's better than Deno just going completely under, I guess.
As an aside, I wonder what's going to happen to the lawsuit that Deno has against Oracle over the name JavaScript. They were asking for 200k in crowdfunding for discovery and received 44k. Will CloudFlare keep it going, or will they just quietly close it down and let Oracle still sit on the name? I also wonder if the legal costs contributed to Deno needing to be bought.