Deno acabou (a Cloudflare encerrou o runtime)

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Deno Is Over (Cloudflare Shut It Down) · Canal: Better Stack · 04:08 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Infraestrutura e hardware de IA, Open source e ecossistemas de software

Resumo

A equipe da Deno vai se juntar à Cloudflare, que encerrará o desenvolvimento do runtime Deno após um ano de atualizações de manutenção. A aquisição não tem como foco o runtime, mas a equipe e o projeto de auto-hospedagem de Durable Objects, que pode ser integrado ao workerd. A Deno Deploy será encerrado em seis meses, enquanto o JSR continuará funcionando na infraestrutura da Cloudflare. A mudança pode facilitar a saída da plataforma, mas deixa usuários do runtime Deno com prazo para planejar uma alternativa.

Pontos-chave

A Deno manterá o runtime por mais um ano, com lançamentos mensais de correções de bugs e atualizações de segurança; depois, encerrará seu desenvolvimento.
A Deno Deploy será encerrado após seis meses, enquanto o JSR migrará para a infraestrutura da Cloudflare.
A Cloudflare está interessada na equipe da Deno e no projeto que permite executar Durable Objects em servidores próprios.
O projeto de auto-hospedagem combina um binário Rust e um bucket de armazenamento para executar aplicações existentes da Cloudflare.
A Cloudflare argumenta que oferecer uma saída por meio de software open source ajuda a conquistar clientes grandes.
A mudança pode afetar serviços que usam runtimes compatíveis com Deno, como Supabase Edge Functions e Netlify Edge Functions.
O apresentador considera positiva a opção de auto-hospedar Durable Objects, mas lamenta o fim do desenvolvimento do runtime Deno.

Capítulos

Início	Capítulo	Resumo
00:00	A aquisição e o futuro dos produtos Deno	A equipe da Deno se junta à Cloudflare, mas o runtime terá apenas mais um ano de desenvolvimento e outros produtos terão destinos diferentes.
01:01	Durable Objects e o projeto de auto-hospedagem	O vídeo explica como Durable Objects funcionam e por que a Cloudflare quer integrar o projeto da Deno que permite executá-los em servidores próprios.
02:35	A saída da plataforma e o impacto nos usuários	A Cloudflare defende que a possibilidade de auto-hospedagem ajuda a conquistar clientes, enquanto usuários de serviços baseados em Deno podem ter decisões a tomar.
03:38	O que a mudança significa para Deno e Workers	O apresentador contrasta o fim do runtime Deno com a continuidade de outros projetos adquiridos e avalia os prós e contras para a Cloudflare e a comunidade.

Citações

Deno acabou. — 00:00

O Deno continuará open source, e damos as boas-vindas a quem quiser continuar seu desenvolvimento. — 00:31

A Deno tinha construído justamente o que a Cloudflare não tinha conseguido. — 02:04

A válvula de escape é o que faz grandes clientes se inscreverem. — 02:35

Para o modelo Workers, acho que isso é positivo. — 03:38

Conceitos e entidades

Deno (ferramenta): Runtime cujo desenvolvimento será encerrado pela equipe após um ano de atualizações de manutenção.
Cloudflare (empresa): Empresa que receberá a equipe da Deno e pretende integrar o projeto de auto-hospedagem ao workerd.
Deno Deploy (ferramenta): Serviço de hospedagem serverless da Deno que será encerrado após seis meses.
JSR (ferramenta): Registro de pacotes que continuará funcionando, migrado para a infraestrutura da Cloudflare.
Rusty V8 (ferramenta): Projeto que continuará recebendo suporte e que a equipe pretende levar ao workerd.
Durable Objects (conceito): Objetos com estado persistente, associados a um banco SQLite próprio, que podem ser endereçados por nome.
workerd (ferramenta): Runtime open source da plataforma Workers da Cloudflare.
Shopify (empresa): Cliente que, segundo a Cloudflare, exigiu que o runtime fosse open source antes de adotar Workers for Platforms.
Supabase Edge Functions (ferramenta): Serviço de funções de borda que, segundo o vídeo, usa um runtime compatível com Deno.
Netlify Edge Functions (ferramenta): Serviço de funções de borda que, segundo o vídeo, usa um runtime baseado em Deno.
Bun (ferramenta): Runtime cuja equipe se juntou à Anthropic, mas que, ao contrário do Deno, continuará em desenvolvimento.
Anthropic (empresa): Empresa à qual a equipe do Bun se juntou, conforme mencionado no vídeo.

Tradução completa (pt-BR)

00:00 A Deno está se juntando à Cloudflare, mas, daqui a um ano, a equipe da Deno vai parar de desenvolver o runtime da Deno. A Deno acabou. Então, por que a Cloudflare comprou a empresa? >> [música] >> Então, é o seguinte: foi anunciado que toda a equipe da Deno está se juntando à Cloudflare. Mas, se você descer um pouco na publicação do blog da Deno, vai encontrar: “Vamos dar suporte ao runtime da Deno por mais um ano, com lançamentos mensais contendo correções de bugs e atualizações de segurança. Depois desse ano, vamos encerrar o desenvolvimento do runtime da Deno.” “A Deno continuará sendo open source,

00:31 e damos as boas-vindas a quem quiser continuar seu desenvolvimento.” Aliás, você não vai encontrar nenhuma menção a isso na publicação da Cloudflare sobre o assunto. É preciso ler a publicação da Deno para saber que isso está acontecendo. Quanto aos outros produtos da Deno, o Deno Deploy, que é uma hospedagem serverless, terá mais seis meses e depois será encerrado completamente. O JSR, o registro de pacotes, continuará funcionando e migrará para a infraestrutura da Cloudflare. E o Rusty V8 continuará recebendo suporte, e eles estão trabalhando para integrá-lo ao Worker D. Então, a pergunta é: por que a Cloudflare está comprando a Deno e depois abandonando o runtime? Bem, a resposta curta é que eles não estão comprando a empresa por causa do runtime. Eles

01:01 querem a equipe e um projeto que a Deno lançou em agosto, chamado Cell D. Para entender por quê, você precisa saber um pouco sobre Durable Objects. Um Durable Object é basicamente um servidor minúsculo com seu próprio banco de dados SQLite, e você o acessa pelo nome. O exemplo do Ryan é um app de chat com um Durable Object por canal. Cada canal tem seu próprio servidorzinho e seus próprios dados. Assim, mais canais significam apenas mais objetos distribuídos por mais máquinas. A escalabilidade está integrada à forma como você escreve o app. E isso é algo que o Ryan queria desde que criou o Node. A demonstração original do Node.js dele era um servidor de chat, e ele diz que sempre o incomodou que ela rodasse em um único servidor

01:32 em uma única thread. Mas a grande ressalva dos Durable Objects era que eles só funcionavam de verdade na Cloudflare. O Worker D, o runtime open source do Workers, só os executa em uma única instância, o que é bom para testes, mas não escala muito bem. E a Cloudflare sabia disso. Kenton Varda, que escreveu a parte da Cloudflare nessa publicação, diz que há comentários de tarefas pendentes sobre isso desde o lançamento original. E ele até tentou construir isso sozinho na primavera passada e, nas palavras dele: “Vergonhosamente, não funcionou.” Então, o Seldi é a resposta da Dino para tudo isso: Durable Objects que escalam na sua própria máquina. É um único binário Rust, mais um

02:04 bucket de armazenamento, e ele executa seu app existente da Cloudflare. Todos os Durable Objects ficam nos seus próprios servidores. Então, a Dino construiu justamente o que a Cloudflare não tinha conseguido construir, e foi por isso que a empresa a incorporou. Agora, o Seldi pode ser integrado ao Worker D, e Ryan e Burt vão liderar o esforço para tornar a hospedagem própria de workers uma opção de primeira classe. Para Ryan, esse é o mesmo caminho que ele vem seguindo: Dino, depois Dino Deploy e, então, Seldi. Executar o Deploy mostrou a ele como a infraestrutura de nuvem fica complicada, e o Seldi foi a tentativa dele de fazer o oposto. O runtime simplesmente deixou de fazer parte do caminho dele. Agora, uma pergunta que você talvez tenha depois de

02:35 tudo isso é por que a Cloudflare quer facilitar a hospedagem própria da Cloudflare. É bastante comum dizer que o Workers foi feito para prender você à plataforma e que o Seldi permite sair. Bem, Kenton diz que essa teoria está errada. Quando apresentaram o Workers for Platforms à Shopify, em 2022, a Shopify não trabalharia com ele a menos que o runtime fosse open source. Então, eles tornaram o Worker D open source, e é o mesmo código que executam em produção. Alguns clientes até o usaram para sair da plataforma. O argumento dele é que a possibilidade de escapar é o que faz os grandes clientes se inscreverem em primeiro lugar. Também vale mencionar que, como estamos em 2026, é claro que há um ângulo de IA nisso também.

03:07 Ryan diz que os Durable Objects são particularmente úteis para agent harnesses, com execução serverless barata, estado persistente e websockets, e é por isso que o Seldi se concentra neles. Então, se você construiu algo com a Dino, agora tem um prazo de um ano, e isso não afeta apenas quem usa a Dino diretamente. As Edge Functions do Supabase rodam em um runtime compatível com a Dino, e as Edge Functions da Netlify rodam em um runtime baseado na Dino. Ainda não vi nenhuma das empresas se pronunciar, mas imagino que elas tenham algumas decisões difíceis a tomar. Também acho que isso faz parte do panorama mais amplo do que está acontecendo no momento. A Bun se juntou à Anthropic em dezembro passado.

03:38 A OpenAI anunciou que estava comprando a Astro, a empresa por trás do UV e do Ruff, e agora a Dino está se juntando à Cloudflare. A diferença em relação a essas duas, porém, é que a Bun e o UV vão continuar, mas a Dino não. Então, no geral, isso é uma coisa boa? Para o modelo do Workers, acho que sim. Durable Objects hospedados por você, com a Cloudflare por trás, são algo muito importante. Isso elimina boa parte do argumento de que a plataforma prende você. Mas, para a Deno, é um prazo de um ano para um runtime de que as pessoas realmente gostavam, e acho que muita gente vai ficar triste, mas a Deno acabou. Conte nos comentários o que você acha. Já que está por aqui,

04:08 inscreva-se e, como sempre, até a próxima.

Transcrição original

[00:00] Deno is joining Cloudflare, but a year from now, the Deno team is going to stop developing the Deno runtime. Deno is over. So, why did Cloudflare buy them? >> [music] >> So, here’s the deal. It’s just been announced that the entire Deno team is joining Cloudflare. But, if you scroll down a bit in the Deno blog post, you will find, “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,

[00:31] and we welcome others who want to continue its development.” You won’t actually find this mentioned in the Cloudflare post about this, by the way. You have to read the Deno one to know that this is going on. As for the other products of Deno, Deno Deploy, that’s serverless hosting, that gets 6 months and then it shuts down completely. JSR, the package registry, keeps running and moves to Cloudflare infrastructure. And Rusty V8 stays supported, and they’re working on bringing that into Worker D. So, the question is, why are Cloudflare buying Deno and then ditching the runtime? Well, the short answer is, they aren’t buying it for the runtime. They

[01:01] want the team and a project that Deno shipped in August called Cell D. To see why, you need to know a bit about Durable Objects. A Durable Object is pretty much a tiny server with its own SQLite database, and you address it by name. Ryan’s example is a chat app with one Durable Object per channel. Every channel gets its own little server and its own data. So, more channels just means more objects spread across more machines. The scaling is built into how you write the app. And that’s something that Ryan’s actually wanted ever since he made Node. His original Node.js demo was a chat server, and he says it’s always bothered him it ran on one server

[01:32] on one thread. The big catch with Durable Objects, though, was they only really ran on Cloudflare. Worker D, which is the open source Workers runtime, only runs them as a single instance, which is fine for testing, but doesn’t really scale well. And Cloudflare knew this. Kenton Varda, who wrote the Cloudflare half of this post, says there’s been to-do comments about this ever since its original release. And he even tried to build it himself last spring, and in his words, “Embarrassingly, it didn’t work.” So, Seldi is Dino’s answer to all of this. Durable objects that scale on your own machine. It’s one Rust binary plus a

[02:04] storage bucket and it runs your existing Cloudflare app. Durable objects are all on your own servers. So, Dino had actually built the thing that Cloudflare hadn’t managed to, which is why they bought them in. Now, Seldi can get merged into Worker D and Ryan and Burt will lead the effort to make self-hosting workers a first-class option. For Ryan, he says this is the same path he’s been on. Dino, then Dino Deploy, then Seldi. Running Deploy showed him how messy cloud infrastructure gets and Seldi was his attempt at the opposite. The runtime is just no longer part of his path anymore. Now, one question you might have after

[02:35] all of this is why Cloudflare wants it to be easier to self-host Cloudflare. It’s a pretty common claim that Workers is built to lock you in and Seldi lets you walk away. Well, Kenton says that that theory is wrong. When they pitched Workers for Platforms to Shopify in 2022, Shopify wouldn’t build on it unless the runtime was open source. So, they open sourced Worker D and it’s the same code they run in production. Some customers have even used it to leave. His point is that the escape hatch is what gets big customers to sign up in the first place. It’s also worth mentioning that since this is 2026, of

[03:07] course, there’s an AI angle to this, too. Ryan says that durable objects are particularly useful for agent harnesses with cheap serverless execution, persistent state and websockets and that’s why Seldi focuses on them. So, if you’ve built on Dino, you now have a one-year clock and that’s not even just people running Dino directly. Supabase Edge Functions run on a Dino-compatible runtime and Netlify’s Edge Functions run on a runtime based on Dino. I haven’t seen either company respond yet, but I’m going to guess they’ve got some hard decisions to make. I also think this is part of the bigger picture going on at the moment. Bun joined Anthropic last

[03:38] December. OpenAI announced that it was buying Astro, the people behind UV and Ruff, and now Dino is joining Cloudflare. The difference with those two, though, is that Bun and UV are carrying on, but Dino isn’t. So, is this a good thing overall? For the Workers model, I think yes. Self-hosted durable objects with Cloudflare behind them is actually a pretty big deal. It takes most of the lock-in argument off the table. But for Deno, it’s a one-year clock on a runtime that people genuinely liked, and I think a lot of people are going to be sad, but Deno is now over. Let me know your thoughts in the comments down below. While you’re there,

[04:08] subscribe, and as always, see you in the next one.