A amizade acabou com o Deno; agora o Node é meu melhor amigo

Artigo original ↗ Discussão no Hacker News ↗

Um post de blog que argumenta que “não há razão para usar Deno hoje” reacende o debate sobre os méritos relativos de Node.js, Deno e Bun como runtimes de JavaScript/TypeScript. Comentadores contrastam a estabilidade, longevidade e o crescente conjunto de ferramentas integradas do Node (como `node:test` e type-stripping de TS) com a cadeia de ferramentas integrada do Deno, seu modelo mais rígido de segurança/permissões e o ecossistema JSR, e com as promessas de desempenho e ergonomia do Bun — temperadas por preocupações com bugs, compatibilidade e o recente drama corporativo. Vários apontam que assistentes de programação com IA agora influenciam fortemente a adoção de runtimes ao defaultarem para stacks populares, o que pode estar acelerando a consolidação em torno de escolhas “chatas” como o Node, mesmo quando alternativas oferecem melhor experiência do desenvolvedor ou segurança.

Runtimes: Node, Deno, Bun

  • Muitos veem o Node como a “aposta chata e segura”: duradouro, estável, com grande chance de sobreviver às runtimes mais novas.
  • O Deno é visto como filosoficamente mais agradável e mais moderno, mas por alguns como cada vez mais caindo no obscurantismo.
  • O Bun recebe elogios por ergonomia e velocidade, mas também preocupação com bugs passados, a reescrita em Rust, a polêmica da aquisição e suposta política em torno de seus criadores.

Por que alguns preferem Bun

  • É elogiado como “mais leve” que Node/Deno: menos dependências, bundler/ferramentas de teste integrados, builds TS fáceis e implantação em binário único.
  • Alguns relatam boa DX e menor necessidade de scripts de shell.
  • Outros contrapõem que, em benchmarks simples, o Node usou menos memória e CPU semelhante, questionando a narrativa de desempenho do Bun.

Por que alguns continuam com Node

  • Considerado maduro, estável e amplamente compatível; desempenho “bom o suficiente”.
  • Alguns dizem que tudo o resto acaba sendo reabsorvido pelo ecossistema do Node.
  • node:test e coverage integrados são apontados como melhorias, embora lint e verificação de tipos ainda precisem de ferramentas extras.

Por que alguns ainda escolhem Deno

  • Pontos fortes: teste/lint/check integrados, história simples de TS, permissões de segurança, JSR/biblioteca padrão e capacidade de compilar para um binário único.
  • Suporte a Desktop/WebGPU e sandboxing são destacados como vantagens únicas, especialmente para uso em agentes/IA.
  • Vários gostam da sensação de “uma CLI, tudo incluído” em contraste com a dispersão de config/ferramentas do Node.

Debates sobre HTTP e compatibilidade

  • Debate acalorado sobre GET HTTP com corpo de requisição:
    • Um lado insiste que isso não é padrão e é inseguro; implementações podem ignorá-lo.
    • Outros observam que ferramentas amplamente usadas (por exemplo, Elasticsearch, alguns clientes GraphQL, tooling de infraestrutura) dependem disso e esperam o comportamento do Node; o comportamento mais estrito do Bun é visto como uma quebra de compatibilidade.

TypeScript e ecossistema

  • Discordância sobre a alegação do artigo de que as limitações de TS do Node são um anti-Microsoft “filosófico”; comentaristas citam razões técnicas concretas (diferenças no tsconfig, desempenho).
  • Alguns argumentam que arquivos de declaração resolvem a maior parte das necessidades de tipagem de bibliotecas; outros só querem um simples type-stripping para código-fonte TS.
  • Divisão mais ampla: alguns veem TypeScript/tipagem forte como essencial para sistemas não triviais, outros enxergam TS como sobrecarga com benefício limitado.

LLMs e escolha de ferramentas

  • Vários observam que LLMs frequentemente defaultam para Node/Bun/Next.js/Supabase, empurrando a adoção.
  • Outros argumentam que usuários competentes devem dizer explicitamente às LLMs qual runtime/stack usar; “LLMs não recorrem a ele” afeta sobretudo a popularidade do produto, não a capacidade.