- Recentemente surgiram críticas e preocupações sobre o momentum do Deno Deploy, KV, Fresh e da empresa e dos projetos como um todo
- Parte das críticas é válida, e o fato de não terem divulgado progresso suficiente por conta própria também acabou aumentando a confusão, mas muitos desses rumores e críticas são especulação sem fundamento ou informações incorretas
- Desde o lançamento do Deno 2 (após outubro de 2023), a adoção mais que dobrou com base na métrica de usuários ativos mensais
- A forte compatibilidade com Node no Deno 2 removeu um grande obstáculo na adoção real, e a plataforma ficou ainda mais rápida, poderosa e simples
Mudanças e evolução do Deno Deploy
- Uma das perguntas mais frequentes é o motivo da recente redução das regiões disponíveis no Deno Deploy
- Por trás da redução, além do custo, houve também mudanças nos padrões reais de uso e nas necessidades
- Para a maioria dos apps, mais importante do que ter todas as regiões é velocidade, depuração e conformidade em regiões próximas aos dados
- Desde o lançamento do Deploy, o número variou de 25 para 35 e agora para 6 regiões
- Muitas regiões quase não eram usadas na prática, e a dispersão excessiva acabava prejudicando o desempenho, com problemas de latência e capacidade
- Estão reconstruindo uma visão prática de “edge” que corresponda às necessidades dos usuários
- Uma nova versão do Deploy está em desenvolvimento, e a plataforma está evoluindo para hospedar aplicações completas
- Deve oferecer suporte a subprocessos, tarefas em segundo plano, OpenTelemetry, pipelines de build, regiões self-hosted e mais
- Em breve, devem disponibilizar recursos para fixar apps em regiões específicas ou executá-los na própria nuvem do cliente
Direção do KV (store de chave-valor)
- O Deno KV é um store com API simples que oferece consistência global garantida, recursos em tempo real e dispensa configuração
- Ele é adequado para dados de sessão, feature flags, estado colaborativo etc., mas não é voltado a bancos de dados de uso geral
- Para necessidades mais amplas de gestão de dados, há dois esforços em andamento
- Fortalecer a integração de bancos de dados relacionais existentes dentro do Deno Deploy
- Avançar em um novo projeto para simplificar a ligação entre computação e estado (inspirado no Cloudflare Durable Objects)
- Seguindo essa direção, o KV permanecerá em beta, com resposta contínua apenas a bugs graves e questões de segurança
- A tendência é que outro projeto assuma no futuro o papel central ou evoluído de uma solução completa de gerenciamento de estado
Situação do framework Fresh
- O Fresh continua sendo a base de todos os apps e sites internos, além de seguir ativamente mantido e aprimorado
- Há consciência da grande expectativa e da longa espera pelo Fresh 2
- Em vez de lançar às pressas, a prioridade é refinar a qualidade e a estrutura fundamentais
- Consulte a postagem do blog sobre as melhorias detalhadas anunciadas recentemente
- A previsão é lançar o Fresh 2 estável ainda este ano
Deno, uma plataforma além do runtime
- O Deno vai além de um simples runtime e é uma plataforma completa de sistema JavaScript
- Com um único conjunto de ferramentas, é possível integrar escrita, execução, testes, deploy e monitoramento
- Integração, configurações padrão, flags e conexões entre ferramentas continuam sendo fortalecidas
- O objetivo não é apenas paridade de funcionalidades, mas a criação de um ecossistema integrado
- A meta é elevar a qualidade essencial do desenvolvimento em JavaScript, expandindo o escopo necessário para isso
Os objetivos e motivos dessa plataforma
- Linguagens de script têm um papel indispensável no desenvolvimento prático e rápido
- O futuro do JavaScript é ainda mais promissor em termos de padronização, ecossistema em larga escala e escalabilidade geral
- É necessária uma plataforma “batteries included”, e o Deno busca isso ao oferecer por padrão gerenciamento de permissões, servidor web, observabilidade, lint, checagem de tipos etc.
- A proposta é oferecer uma experiência unificada em vez de ferramentas fragmentadas
Planos futuros e reforço na comunicação
- O Deno não está encolhendo; está entrando em uma fase de expansão
- A plataforma continua melhorando em velocidade, compatibilidade e maturidade, enquanto o JSR cresce com governança independente
- Também seguem em paralelo atividades voltadas ao ecossistema JavaScript e colaboração com a comunidade, como TC39/WinterTC
- Com base nas experiências com o Deploy e o KV, estão desenvolvendo novos produtos sustentáveis e distribuídos, e mais novidades devem ser divulgadas em breve
- Para reduzir controvérsias e desconfiança, a empresa pretende fortalecer a comunicação e dar grande importância à confiança dos desenvolvedores
3 comentários
Ou o Bun é melhor que o Deno?
Os rumores sobre o declínio do Deno são muito exagerados
Parece que isso é uma resposta a esse post.
Também foi publicado separadamente um texto sobre por que a atualização do Fresh está demorando: Atualização do Fresh 2, o framework web do Deno
Opinião do Hacker News
Desde o início, já parecia claro que a maioria dos desenvolvedores não implanta apenas funções stateless simples, e sim constrói aplicações reais que se comunicam com bancos de dados, como apps full stack. Dá até a sensação de que perceber isso só agora era meio inevitável.
Compartilha a percepção de que houve críticas recentes ao Deno, ao Deploy, ao KV, ao Fresh e ao crescimento da empresa em geral. Sobre as críticas ao crescimento, diz que não viu menção nem resposta específica, e se pergunta se isso foi intencional. Como foi dito que parte das críticas era válida, acha que teria passado mais confiança se tivessem divulgado quais críticas eram válidas e como pretendiam resolvê-las. Considera positivo, na hora de escolher uma empresa, quando ela reconhece até os próprios pontos fracos. Compartilha que gosta da transparência de páginas de prós e contras como a da Migadu.
No início, a expectativa em relação ao Deno vinha do fato de ele poder recomeçar de forma limpa, com menos complexidade, sem ficar obcecado com compatibilidade com o passado. Havia algumas partes mais incômodas que no Node, mas pareciam administráveis. Só que, em vez de apostar nas próprias soluções, ele foi se prendendo cada vez mais à compatibilidade com Node, e agora acabou virando uma estrutura dupla que parece até mais complexa que o próprio Node. Faz sentido que pacotes Node funcionem no Deno, mas há muitos casos de borda em que não funcionam por APIs ainda não implementadas ou bugs. O AVA, que era seu framework de testes favorito, ainda não é suportado. Antes, ignorava a camada de compatibilidade com npm e usava só o Deno em si, mas isso está ficando cada vez mais incômodo. Basta olhar as opções de linha de comando: em poucos anos ficaram absurdamente mais complexas, e a maioria existe para integração com npm, então para ele é só informação inútil. O que mais queria em compatibilidade com Node era suporte à configuração do ESLint no linter do Deno, mas isso parece não interessar ao projeto. Ainda assim, quer que o Deno tenha sucesso porque ele pressiona o Node a melhorar. Só que a direção atual do Deno já não parece consistente com o propósito original.
Dá a sensação de que o Deno perdeu a direção. No começo, o posicionamento era simples: um runtime JS/TS seguro e rápido, feito em Rust. Agora, o menu suspenso “Products” do site está cheio de vários produtos adicionados de forma bagunçada. Parece que tentaram seguir o caminho da Vercel, que fez uma plataforma de deploy depois do NextJS.
A expectativa acabou no momento em que o Deno desistiu da promessa inicial ao adicionar compatibilidade com Node. Para essa pessoa, o maior atrativo do Deno era justamente remover a complexidade indesejada e o legado do Node, mas agora quase não resta diferença além de alguns detalhes como TypeScript embutido e permissões. O bun.sh também oferece compatibilidade com Node. Pergunta se alguém conhece um motor de scripting TypeScript para servidor que não busque compatibilidade com Node.
Compatibilidade com npm é um acréscimo de funcionalidade, então não vê por que isso significaria perder alguma coisa. Ninguém é obrigado a usar APIs de Node, e usar apenas as bibliotecas desejadas do jsr.io já é suficiente. Na prática, argumenta que ainda dá para ter no Deno uma experiência de desenvolvimento diferente da do Node. Mas, como não há tanta gente assim buscando “pureza” total, considera até positivo terem escolhido popularidade e pragmatismo.
Questiona por que alguém procuraria um runtime TypeScript sem compatibilidade com Node. O Node tem vários problemas, mas ainda assim é suficientemente útil para ser amplamente adotado. Para criar uma alternativa prática, seria necessário ou (1) ter vantagens fortes o bastante para justificar uma migração em grande escala, ou (2) ao menos oferecer custo mínimo de migração junto com melhorias claras em desempenho, confiabilidade ou usabilidade. Na visão dessa pessoa, o Deno falha em ambos. Ele não roda bem o código Node existente, mas também não oferece vantagens revolucionárias suficientes, ficando preso a um caminho que acaba atraindo apenas “idealistas” ou “desenvolvedores por hobby”.
Como runtime TypeScript sem foco em compatibilidade com Node, vem à mente o workerd do Cloudflare Workers, mas no fundo ele não é um runtime backend de propósito geral e tem a limitação de praticamente não oferecer pacotes padrão ou funcionalidades embutidas.
Pessoalmente, prefere usar JSDoc. Isso traz vantagens parecidas sem relação com Node e sem a complexidade de uma cadeia de compilação.
Se não há necessidade de ficar preso a JS no backend, considera mais racional pensar em alternativas melhores em vez de TypeScript. Se for possível controlar toda a stack, não haveria motivo para permanecer em uma linguagem que compila para JS.
Acha que o texto recente provavelmente foi uma reação a https://news.ycombinator.com/item?id=43863937.
Embora seja um texto escrito pelo CEO, ele parece mais focado em justificar decisões internas do que em responder críticas concretas ao Deno. Ainda assim, a impressão é que a linha de produtos do Deno funciona razoavelmente bem dentro do ambiente Deno.
Ainda não há confiança nem convicção. Em breve deve dar para ver como o Deploy vai evoluir, mas, no caso do KV, se não houver intenção de desenvolver mais além do beta, acha que não há motivo nenhum para usá-lo em novos projetos. Dizem que o Fresh será refatorado para alfa perto do fim do Q3, mas ele já era um framework que basicamente só oferecia o mínimo, e até sua estrutura sem build/compilação, que era o ponto mais visível, vai desaparecer. O runtime continua em desenvolvimento, mas é curioso que as notas de versão estejam tão focadas em compatibilidade com Node/NPM, mesmo com a declaração de que “não buscamos paridade de funcionalidades com outros runtimes”.
Considera uma péssima decisão interromper o desenvolvimento contínuo do KV. Aponta que as empresas não deixam de usar KV porque a funcionalidade é ruim, e sim por causa do rótulo de beta. Diz que usou bastante o Cloudflare Workers KV e nunca teve grande interesse em Durable Objects, então tinha expectativa no Deno KV, mas agora parece que terá de tirá-lo das opções consideradas. Avalia que anunciar um produto novo e logo em seguida deixá-lo de lado passa uma impressão estratégica muito ruim.
Compartilha de forma sincera que estava pensando em usar KV, mas, sem enxergar perspectivas, passou a considerar alternativas.
Fica a dúvida se essa observação de que a maioria dos desenvolvedores implanta não funções stateless simples, mas apps full stack fortemente integrados a bancos de dados, vale de fato para o movimento serverless como um todo. Se for o caso, questiona se isso está alinhado com a proposta original do serverless ou se a escolha acontece apenas para evitar infraestruturas complexas como Docker/Kubernetes.
Explica que o Deno recebe com frequência perguntas sobre a redução no número de regiões do Deno Deploy. A posição da empresa é que a maioria dos apps não precisa rodar em todos os lugares do mundo, e que o ideal é otimizar para ficar perto dos dados, ser rápido, fácil de depurar e adequado às exigências regulatórias locais. Mas a pessoa diz que, na prática, não usou o Deno Deploy porque a localização das regiões não era próxima o bastante, o que gerava preocupação com desempenho. Como já existem várias opções mais próximas tanto dos dados quanto dos usuários, e conformidade regulatória costuma bastar em nível de país na maioria dos casos, considera essa direção de otimização pouco convincente.