Deno em 2023

Deno Deploy, Regiões e Viabilidade do Negócio

• Relata-se que o Deno Deploy encolheu de 35 para 12 regiões da GCP.
• Alguns veem isso como um corte de custos sensato para uma startup; outros temem que sinalize crescimento fraco e possa afastar usuários que precisam de regiões específicas.
• Preocupação com risco de fornecedor: se a hospedagem falhar, o runtime/ecossistema do Deno sobreviverá? Muitos presumem que sim por ser open source e permitir auto-hospedagem, mas isso não é garantido.

JSR e Ecossistema de Pacotes

• JSR é entendido como um registro de pacotes JavaScript com foco em TypeScript e uma alternativa de fato ao npm.
• Reações mistas: mensagens anteriores do Deno sugeriam que imports por URL evitariam a necessidade de um registro; agora parece que estão mudando de rumo, possivelmente aprendendo com a experiência.

Compatibilidade com Node/Bun e Proposta de Valor

• O Deno se moveu em direção à compatibilidade com Node (por exemplo, package.json, integração com npm), em parte porque a não compatibilidade prejudicava a adoção.
• Bun é visto como uma substituição mais rápida e direta do Node, enquanto o Deno busca “reimaginar o Node” com APIs padrão da web e ferramentas integradas (TS, testes, linting, formatação, bundling).
• Alguns argumentam que, se o Node adotasse recursos integrados semelhantes, Deno/Bun perderiam grande parte do apelo.

Experiência do Desenvolvedor: Prós e Contras

• Pontos pró-Deno:
  • Instalação em binário único; atualizações fáceis.
  • Suporte a TS pronto para uso, incluindo REPL.
  • Padrões sensatos; um arquivo de configuração em vez de muitos.
  • stdlib e ferramentas embutidas reduzem a proliferação de dependências e o risco da cadeia de suprimentos.
  • Bom para scripts pontuais e CLIs; pode compilar para um binário único.
• Críticas:
  • Imports por URL podem ser incômodos (especialmente em repositórios privados).
  • O modelo de permissões pode parecer trabalhoso; alguns acabam usando --allow-all amplo.
  • Executar múltiplos processos de CPU / clustering é mais fraco do que a história de cluster+pm2 do Node para implantações em bare metal.

Tamanho da Compilação e Implantação

• Binários compilados cresceram de ~50MB para ~90MB+, o que alguns consideram grande demais para implantação no estilo Go, limites de serverless ou muitas ferramentas pequenas.
• Outros argumentam que 90–100MB é aceitável para muitos casos de servidor/CLI, especialmente por ser autocontido; críticos respondem que o tamanho importa para FaaS, CI/CD e muitas instâncias.
• Membros da equipe do Deno relatam trabalho em andamento que já reduziu o tamanho base do binário em cerca de 40% em testes, com mais melhorias esperadas.

Frameworks, Hospedagem e Next.js/Fresh

• O framework Fresh do Deno é visto como concorrente do Next.js; alguns temem que sua existência reduza o incentivo para fazer o Next.js funcionar bem no Deno.
• Outros argumentam que o Next.js/Vercel também são fortemente acoplados, então é razoável que o Deno promova sua própria stack enquanto ainda melhora o suporte ao Next.js.
• Fresh é considerado promissor, mas “ainda não pronto” para projetos grandes; o tooling de CSS (além de Tailwind/CSS puro) é visto por alguns como imaturo.
• O Deno Deploy é elogiado pela simplicidade, mas criticado por cold starts e, agora, por ter menos regiões.

Deno KV e Dados

• O Deno KV é comparado ao datastore do App Engine: chave-valor com indexação manual e transações.
• Funciona bem para registros pequenos; os limites rígidos de tamanho o tornam inadequado para blobs grandes.
• O tooling de desenvolvimento local para KV é descrito como agradável; a experiência em produção no tópico é limitada, mas cautelosamente positiva.

Segurança e Sandboxing

• O modelo de permissões do Deno (sem acesso a FS/rede/ambiente por padrão) é visto como um diferencial central e útil para limitar módulos de terceiros (por exemplo, rede apenas para hosts específicos).
• Críticos observam que isolamento semelhante pode ser obtido via contêineres ou sandboxing do SO; outros apontam que permissões embutidas funcionam em múltiplas plataformas sem o overhead de contêineres e agregam valor mesmo quando não há contêinerização.

Multithreading e Concorrência

• Surge a კით de por que alternativas ao Node (incluindo o Deno) não têm “verdadeiro” multithreading além de workers.
• Alguns argumentam que cargas de trabalho em JS são naturalmente assíncronas e podem aproveitar workers/C++ addons; outros dizem que multithreading real seria amplamente útil, mas é difícil de adaptar ao ecossistema assíncrono existente sem problemas de data races.

Novos Casos de Uso e Integrações

• Jupyter + Deno é bem-vindo para pessoas fluentes em JS/TS que só ocasionalmente trabalham com dados, evitando o atrito de dependências do Python.
• Os hooks de WebGPU e janela do Deno despertam interesse para construir GUIs desktop em JS/TS sem empacotar um navegador completo (Electron); porém, a criação de janelas e o input/acessibilidade ainda dependem de bibliotecas nativas extras, então a história está incompleta.

Sentimento Geral

• Muitos expressam forte entusiasmo pelo design, pelas ferramentas e pela marca do Deno, e relatam experiências de produção tranquilas para apps pequenos e médios.
• Céticos questionam a viabilidade de longo prazo, os tamanhos dos binários, certos recursos ausentes (clustering, ecossistema rico de GUI, tooling de CSS) e a necessidade de mais um runtime/registro de JS.