A Guerra dos Runtimes JavaScript Ficou Chata (E Isso é Ótimo)

Por anos, escolher entre Node.js, Deno e Bun foi uma declaração de valores tanto quanto uma decisão técnica. Em 2026 essa fase acabou: os três runtimes convergiram para o mesmo conjunto de garantias básicas — compatibilidade com o ecossistema npm, TypeScript sem etapa de build separada e performance competitiva — e a escolha virou, finalmente, sobre requisitos concretos do projeto.

Bun 2.0: o Node de verdade, mais rápido

A Oven lançou o Bun 2.0 em maio de 2026 com estabilidade de verdade no Windows (historicamente o ponto fraco do runtime), compatibilidade de API com o Node em torno de 99,4% e suporte nativo a S3, encerrando a era em que 'testar se seu projeto roda no Bun' era um passo obrigatório antes de qualquer deploy. Builds e cold start seguem sensivelmente mais rápidos que o Node em benchmarks de I/O e HTTP — o diferencial que sempre foi a proposta de valor do Bun continua de pé.

Deno: menos sobre segurança, mais sobre compatibilidade

O Deno, que nasceu com o discurso de sandbox por padrão e permissões explícitas, passou os últimos ciclos investindo pesado em compatibilidade retroativa: modo node_modules completo, resolução de package.json e suporte a workspaces monorepo praticamente equivalente ao Node. A proposta original de segurança por padrão não desapareceu — continua lá para quem ativamente escolhe esse modelo — mas deixou de ser a única porta de entrada. Hoje dá pra rodar um projeto Node legado no Deno sem reescrever nada, o que era impensável nas primeiras versões.

Node.js: o incumbente absorveu as boas ideias

O Node também não ficou parado. TypeScript nativo — rodar arquivos .ts diretamente, sem transpilação prévia via ts-node ou tsx — deixou de ser experimental e virou capacidade padrão amplamente adotada em 2026, fechando uma das maiores vantagens de DX que Bun e Deno tinham sobre ele. Some a isso o ecossistema mais maduro do mercado (nenhum runtime novo replica 15 anos de pacotes, tooling e conhecimento acumulado) e o argumento 'só uso Node porque é o padrão' deixou de ser preguiça e virou, de novo, uma escolha racional.

• Escolha Bun quando: performance de I/O/HTTP é crítica, você já não depende de bibliotecas nativas exóticas e quer o menor tempo de cold start
• Escolha Deno quando: segurança por permissão explícita importa de verdade (múltiplos tenants, código de terceiros em produção) ou você já está no ecossistema Deno Deploy/edge
• Escolha Node quando: seu time e sua infraestrutura já são Node, a superfície de risco de migrar não compensa o ganho, ou você depende de módulos nativos C++ com suporte só ao Node-API tradicional
• Em todos os três: TypeScript direto, sem build step, já é expectativa padrão — se sua stack ainda exige transpilação manual só pra rodar localmente, vale revisar

# 2026: TypeScript nativo nos três runtimes, sem transpilação prévia
node app.ts        # Node.js — suporte nativo amplamente adotado
deno run app.ts    # Deno — nativo desde a v1
bun run app.ts     # Bun — nativo desde o início