Deno, Bun e a guerra dos runtimes JavaScript — por que Node.js não é mais o padrão

Ryan Dahl criou o Node.js em 2009 e mudou o desenvolvimento no lado do servidor permanentemente. Pela primeira vez, JavaScript — uma linguagem que os desenvolvedores já conheciam do navegador — podia ser executado em servidores, permitindo JavaScript full-stack e um ecossistema que eventualmente se tornou o maior registro de pacotes da história com mais de 2,5 milhões de pacotes no npm. Por 15 anos, Node.js foi o padrão incontestável para qualquer um que quisesse executar JavaScript fora de um navegador.

Então Ryan Dahl fez uma palestra no JSConf EU em 2018 intitulada "10 coisas que lamento sobre o Node.js" e anunciou o Deno. A palestra foi excepcionalmente sincera para um autor criticando sua própria criação: o sistema de módulos estava errado, o modelo de segurança estava ausente, package.json e node_modules foram erros, e o design original havia acumulado muitas restrições para serem corrigidas sem um recomeço. Três anos depois, uma equipe diferente entregou o Bun — um runtime JavaScript com desempenho como seu objetivo central de design, construído do zero em Zig em vez de C++.

Node.js: O peso do legado

Node.js funciona no motor V8 JavaScript (o mesmo motor que alimenta o Chrome) e acumulou 15 anos de obrigações de retrocompatibilidade. Seu sistema de módulos — CommonJS (require/module.exports) — antecede o padrão ES Modules que os navegadores agora usam, criando um atrito crônico de interoperabilidade que nunca foi resolvido de forma limpa. Node.js adicionou suporte a ES Module na versão 12 (2019), mas a coexistência de dois sistemas de módulos, com suas diferentes semânticas em torno de carregamento síncrono vs assíncrono, tem sido uma fonte persistente de confusão para desenvolvedores e fragmentação do ecossistema.

O modelo de segurança também é uma fraqueza reconhecida. Node.js dá a qualquer script acesso completo ao sistema de arquivos, rede e variáveis de ambiente por padrão. Isso tornou o desenvolvimento inicial rápido, mas cria um risco significativo em um mundo onde ataques à cadeia de suprimentos do npm são rotineiros. Um pacote malicioso instalado como dependência transitiva tem, por padrão, o mesmo acesso ao seu sistema que o código da sua aplicação.

Node.js continua sendo o runtime JavaScript do lado do servidor mais amplamente implantado por uma margem substancial — o ecossistema npm é construído em torno dele, a maioria dos frameworks JavaScript o mira primeiro, e a maioria das implantações de produção roda nele. O legado não vai embora. Mas criou espaço para alternativas.

Deno: TypeScript primeiro, segurança por padrão

Deno é a tentativa de Ryan Dahl de corrigir os erros que cometeu com o Node.js. Ele executa TypeScript nativamente — nenhuma etapa de compilação necessária, nenhum tsconfig.json necessário para uso básico — o que aborda um dos pontos de atrito mais comuns no desenvolvimento JavaScript moderno. Ele usa exclusivamente o sistema ES Modules, eliminando a divisão CommonJS/ESM. E implementa um modelo de permissões onde scripts devem solicitar explicitamente acesso ao sistema de arquivos, rede e ambiente: `deno run --allow-net --allow-read server.ts`.

A compatibilidade com Web API do Deno é uma escolha de design significativa. APIs padrão do navegador — fetch, WebCrypto, URL, WebSockets, Streams — funcionam no Deno sem nenhum polyfill. Código escrito para Deno muitas vezes pode rodar em navegadores com modificação mínima, o que se alinha com a direção moderna do JavaScript como uma linguagem universal em vez de variantes específicas de plataforma. Cloudflare Workers, Vercel Edge Functions e Deno Deploy todos rodam em isolates V8 com superfícies de Web API semelhantes, tornando o código Deno altamente portátil entre plataformas de implantação edge.

O modelo de gerenciamento de pacotes é diferente do npm: Deno importa módulos diretamente de URLs (incluindo pacotes npm via especificadores `npm:`), sem diretório node_modules e sem necessidade de package.json para casos de uso simples. O arquivo de configuração deno.json lida com o travamento de dependências através de um import map. Este modelo é mais limpo, mas adiciona uma curva de aprendizado para desenvolvedores treinados em fluxos de trabalho npm.

A adoção do Deno tem sido substancial no espaço de edge computing — Deno Deploy e sua integração com o ecossistema Deno é um produto competitivo — mas não deslocou o Node.js em aplicações de servidor tradicionais. A compatibilidade com o ecossistema npm adicionada no Deno 1.28 (novembro de 2022) reduziu significativamente o atrito de migração, mas a maioria das cargas de trabalho de produção permanece no Node.js.

Bun: Velocidade como princípio de design

Bun adota uma abordagem diferente. Onde Deno é uma história de correção e segurança, Bun é uma história de desempenho. Construído em Zig (uma linguagem de programação de sistemas projetada para desempenho) e usando o motor JavaScriptCore da Apple (o mesmo motor que alimenta o Safari, e nos próprios benchmarks da Apple, mais rápido que o V8 para certas cargas de trabalho), Bun é projetado para ser o runtime JavaScript mais rápido disponível.

As alegações dos benchmarks são significativas: os benchmarks do servidor HTTP do Bun mostram uma taxa de transferência 2–4x maior que o Node.js para manipuladores de requisição simples. Benchmarks de E/S de arquivo mostram vantagens semelhantes. A instalação de pacotes do Bun é mais rápida que npm, yarn ou pnpm — tipicamente 5–30x mais rápida dependendo do cenário — o que melhora significativamente a experiência do desenvolvedor em ambientes CI/CD e fluxos de trabalho conteinerizados.

Bun também se posiciona como um kit de ferramentas tudo-em-um: é um runtime, um gerenciador de pacotes (substituindo npm), um bundler (substituindo webpack ou esbuild) e um executor de testes (substituindo Jest ou Vitest). A filosofia de design é reduzir o número de ferramentas na pilha de desenvolvimento JavaScript, que historicamente exigia a montagem de 5–10 ferramentas separadas para uma configuração pronta para produção.

A compatibilidade com Node.js é uma alta prioridade para o Bun — ele suporta CommonJS e ES Modules, implementa a maioria das APIs embutidas do Node.js e pode executar a maioria dos pacotes npm sem modificação. Bun 1.0, lançado em setembro de 2023, foi a primeira versão pronta para produção; versões subsequentes melhoraram progressivamente a compatibilidade com Node.js a ponto de a maioria das aplicações Node.js rodar no Bun sem alterações.

A ressalva de desempenho

As vantagens de desempenho do Bun são reais, mas dependem do contexto. Para cargas de trabalho com limite de E/S — servidores HTTP, consultas a banco de dados, operações de arquivo — os ganhos do Bun sobre o Node.js são mensuráveis e significativos. Para cargas de trabalho com limite de CPU ou aplicações limitadas por sistemas externos (latência de banco de dados, tempos de resposta de API), o runtime JavaScript raramente é o gargalo, e trocar de runtime fornece benefício mínimo.

A troca entre JavaScriptCore e V8 também tem nuances: o compilador JIT do V8 foi otimizado por 15 anos para cargas de trabalho web de produção. As características de desempenho do JavaScriptCore diferem do V8 de maneiras que podem produzir resultados diferentes em benchmarks específicos versus comportamento real de aplicação. Os números de "2–4x mais rápido" dos benchmarks do Bun refletem cargas de trabalho sintéticas; acelerações em aplicações de produção são tipicamente de 10–30%.

O que usar de fato

O guia prático em 2026: Node.js para projetos existentes e equipes com fluxos de trabalho npm estabelecidos, onde o custo da migração supera as melhorias marginais de desempenho. Deno para novos projetos onde desenvolvimento TypeScript-first, implantação edge ou postura de segurança são prioridade — particularmente projetos que visam Cloudflare Workers, Deno Deploy ou plataformas edge semelhantes. Bun para projetos onde a experiência do desenvolvedor (instalações rápidas, execuções de teste rápidas) e a latência de inicialização importam, e onde a equipe está confortável com um ecossistema mais novo e menos testado em produção que o Node.js.

A concorrência também melhorou o Node.js. Os tempos de inicialização mais rápidos no Node.js 20+, o suporte melhorado a ESM e o modelo de permissão sendo explorado no roteiro do Node.js são respostas diretas ao Deno e ao Bun. Para um ecossistema de linguagem que não teve concorrência significativa por 15 anos, a pressão tem sido produtiva. O runtime JavaScript em 2026 é genuinamente uma escolha, não um padrão.