Cloudflare adquire a Deno

Artigo original ↗ Discussão no Hacker News ↗

A aquisição da empresa Deno pela Cloudflare levará a equipe da Deno e sua tecnologia celld para o ecossistema Workers da Cloudflare, enquanto o runtime Deno open source em si receberá apenas atualizações de bugs e segurança por mais um ano antes de o desenvolvimento oficial parar. Comentadores veem isso em grande parte como uma acquihire e um golpe para runtimes independentes de JavaScript/TypeScript, com muitos usuários agora planejando migrações de volta para Node.js ou para alternativas como Bun e workerd. O movimento levanta preocupações mais amplas sobre a sustentabilidade de ferramentas open source financiadas por VC, a consolidação de runtimes em grandes plataformas e a necessidade de governança apoiada pela comunidade ou por fundações para garantir estabilidade de longo prazo.

Aquisição e Encerramento do Runtime Deno

  • A equipe da Deno está se juntando à Cloudflare; o runtime Deno receberá apenas versões de correção de bugs/segurança por ~1 ano e, depois disso, o desenvolvimento ativo pela equipe original para.
  • Muitos leitores veem isso como uma acquihire e um encerramento efetivo, em vez de “a Deno se juntando à Cloudflare”.
  • Alguns criticam que isso estava explícito no post da Deno, mas foi minimizado ou ausente no post da Cloudflare.

celld, workerd e a Estratégia da Cloudflare

  • O interesse da Cloudflare é visto principalmente no celld e na experiência da equipe com runtimes, e não no runtime Deno em si.
  • Plano: mesclar o modelo de Durable Objects auto-hospedado do celld ao workerd open source da Cloudflare para criar um runtime Workers/Durable Objects de primeira classe e auto-hospedável.
  • Funcionários da Cloudflare no tópico enfatizam: workerd + celld continuarão open source e visam tornar KV/queues/etc. plugáveis em infraestrutura comum (por exemplo, storage de objetos no estilo S3).

Por que o Deno “fracassou” (segundo os comentaristas)

  • Teorias comuns:
    • O modelo apoiado por VC para um runtime + hospedagem (Deploy) era insustentável.
    • Node era “bom o bastante” e enorme; o Deno não entregou uma melhoria 10x.
    • A recusa inicial em suportar npm/node_modules prejudicou a adoção; depois, adicionar compatibilidade diluiu sua visão original.
    • A compatibilidade agressiva com Node e a velocidade do Bun roubaram atenção.
  • Comentários da equipe do Deno dizem que o Deno estava sendo puxado para compatibilidade total com Node, tornando-se “apenas mais um Node”, enquanto o celld é uma abstração mais nova.

Impacto para Usuários e Ecossistema

  • Algumas empresas e projetos construídos fortemente sobre Deno (plataformas serverless, ferramentas internas, integração com yt-dlp, apps hobby TUI/desktop) agora enfrentam trabalho de migração.
  • As opiniões sobre a dificuldade divergem:
    • Muitos dizem que migrar para Node/Bun pode ser largamente automatizado com LLMs e levar “um ou dois dias”, a menos que esteja preso a APIs específicas do Deno (Deno.serve, KV, Deploy).
    • Outros enfatizam o lock-in de plataforma e o desgaste de burocracia/processo.

Open Source, Financiamento e Consolidação

  • O tópico questiona repetidamente modelos de runtime com VC + OSS; muitos argumentam que o Deno deveria ter permanecido um projeto OSS enxuto, financiado por patrocinadores.
  • Há preocupação com a consolidação: Bun → Anthropic, múltiplas ferramentas de dev → gigantes de IA/cloud, agora Deno → Cloudflare.
  • Alguns observam que as ideias da Deno já levaram o Node a adicionar permissões, stripping de TS, apps de executável único; a competição é vista como tendo melhorado o Node.

Futuro dos Artefatos em Torno do Deno

  • O runtime Deno é MIT; pessoas discutem possíveis forks da comunidade (“opendeno”).
  • Participantes da Cloudflare dizem que rusty_v8 e JSR continuarão e serão integrados/hospedados na Cloudflare.
  • Se um sucessor viável do Deno liderado pela comunidade surgirá é amplamente visto como incerto.