Bun: O runtime que quer aposentar o Node (e agora tem grana para isso)

A notícia que ninguém viu chegando

Na semana passada, enquanto você e eu estávamos tranquilamente brigando com o node_modules, a Anthropic soltou uma bomba: compraram o Bun.

Sim, a empresa por trás do Claude decidiu que seu futuro passa por um runtime de JavaScript escrito em Zig por um cara que pensou “e se fosse Node, mas rápido?”. O Claude Code acabou de alcançar um bilhão de dólares em receita, e aparentemente a primeira coisa que você faz quando sobra grana é comprar ferramentas de desenvolvimento.

Por quê? Porque o Claude Code executa JavaScript a rodo, e cada milissegundo conta quando você tem milhões de usuários. Em outras palavras: se seu negócio depende de executar código rápido, você compra o runtime mais rápido.

Mas chega de fofoca empresarial. Vamos ao que te interessa: o que é Bun e por que deveria te importar.

O que é Bun (para quem vem do Node)

Bun é como se alguém tivesse olhado para o ecossistema do Node e disse: “E se ao invés de ter quinze ferramentas fizéssemos uma que substitui todas?”

Onde antes você tinha:

node          → runtime
npm/pnpm/yarn → gestor de pacotes
webpack/esbuild/vite → bundler
jest/vitest   → test runner
ts-node/tsx   → executar TypeScript

Agora você tem:

bun           → tudo isso acima

É o patinete elétrico contra o carro com reboque. Menos peças, menos coisas que podem quebrar, e curiosamente mais rápido.

Os números que importam

Não gosto de fazer benchmarks porque sempre podem ser manipulados. Mas esses números são tão brutais que vale a pena mencionar:

Por que é tão rápido? Porque está escrito em Zig ao invés de C++, e porque Jarred Sumner (o criador) é um desses programadores que otimiza código como hobby. O cara trabalhava no Stripe e decidiu que o problema mais importante do mundo era que npm install demorava demais.

E, cara, talvez ele estivesse certo.

O que já funciona (e o que não)

O Bun é compatível com a maioria das APIs do Node. Se seu código usa fs, path, http, ou qualquer módulo padrão, provavelmente funciona sem mudanças.

Funciona bem

• Next.js: Suporte oficial. bun run dev e pronto.
• Express/Fastify: Sem problemas.
• A maioria dos pacotes npm: Bun lê package.json e node_modules igual ao Node.
• TypeScript: Nativo, sem configuração.
• JSX: Também nativo.

Pode dar problemas

• Pacotes com bindings nativos do Node: Alguns precisam ser recompilados.
• Código que depende de quirks específicos do V8: Bun usa JavaScriptCore (o motor do Safari).
• Algumas APIs do Node muito específicas: Workers, algumas partes do cluster.

Não funciona (ainda)

• Windows: Funciona, mas com algumas limitações.
• Yarn PnP: Não suportado.

Seu primeiro projeto com Bun

Se você já tem Node, instalar o Bun é um comando:

curl -fsSL https://bun.sh/install | bash

Ou se você usa macOS e Homebrew:

brew install oven-sh/bun/bun

Verifique se funciona:

bun --version

Criar um projeto novo

mkdir meu-projeto && cd meu-projeto
bun init

Isso gera um package.json, um tsconfig.json, e um index.ts. Sem perguntas, sem wizards. Assim eu gosto.

O arquivo que gera

// index.ts
console.log("Hello via Bun!");

Execute:

bun run index.ts

Sim, executa TypeScript diretamente. Sem transpilar. Sem ts-node. Sem nada.

Migrando do pnpm

Se você tem um projeto com pnpm, a migração é surpreendentemente simples:

# Opção 1: Regenerar lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

# Opção 2: Usar o lockfile existente (experimental)
bun install

O Bun gera seu próprio bun.lockb (binário, mais rápido de parsear). Você pode manter ambos os lockfiles durante a transição se trabalha em equipe e nem todos migraram.

O package.json não muda

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "test": "vitest"
  }
}

Você continua executando bun run dev, bun run build, bun run test. Os scripts funcionam igual.

Testes: do Vitest para o Bun

O Bun tem seu próprio test runner que é compatível com a API do Jest/Vitest:

// sum.test.ts
import { expect, test } from "bun:test";
import { sum } from "./sum";

test("2 + 2 = 4", () => {
  expect(sum(2, 2)).toBe(4);
});

Execute com:

bun test

E se eu quiser continuar com Vitest?

Funciona perfeitamente. O Bun pode executar o Vitest como runtime:

bun run vitest

Você obtém a velocidade de inicialização do Bun com as features do Vitest. O melhor dos dois mundos.

O servidor HTTP mais rápido que você verá

O Bun inclui um servidor HTTP que deixa o Express chorando no cantinho:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Olá do Bun!");
  },
});

console.log("Servidor em http://localhost:3000");

Usa a API padrão do fetch (Request/Response), então se você vem do Cloudflare Workers ou Deno, vai se sentir em casa.

Benchmark de hello world

Na minha máquina (M1 Pro), um servidor de hello world:

• Express: ~15,000 req/s
• Fastify: ~45,000 req/s
• Bun.serve: ~150,000 req/s

Sim, dez vezes mais rápido que o Express. Não, não é erro de digitação.

Variáveis de ambiente

O Bun carrega .env automaticamente. Sem dotenv. Sem configuração.

# .env
DATABASE_URL=postgres://localhost/mydb

// index.ts
console.log(Bun.env.DATABASE_URL);

Pronto. Funciona e ponto final.

SQLite integrado

Isso explodiu minha cabeça. O Bun traz SQLite integrado:

import { Database } from "bun:sqlite";

const db = new Database("mydb.sqlite");
db.run("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");
db.run("INSERT INTO users (name) VALUES (?)", ["Fernando"]);

const users = db.query("SELECT * FROM users").all();
console.log(users);

Nada de instalar better-sqlite3 ou sql.js. Simplesmente funciona.

O bundler

O Bun também pode empacotar seu código para produção:

bun build ./index.ts --outdir ./dist

É mais rápido que o esbuild (que já era ridiculamente rápido). Para a maioria dos projetos, gera bundles equivalentes.

Se você precisa de algo mais sofisticado (code splitting, tree shaking avançado), provavelmente ainda vai precisar do Vite ou webpack. Mas para muitos casos, isso é suficiente.

Quando NÃO usar Bun

Porque nem tudo são flores:

1. Produção crítica onde você não pode experimentar: Bun é estável, mas Node tem 15 anos de bugs resolvidos.

2. Pacotes com bindings nativos muito específicos: Alguns precisam de trabalho extra.

3. Windows como plataforma principal: Funciona, mas o suporte de primeira classe é para macOS/Linux.

4. Sua equipe não quer aprender nada novo: Às vezes a melhor ferramenta é aquela que todo mundo sabe usar.

Quando SIM usar Bun

1. CI/CD: O tempo de install reduzido economiza dinheiro real. Sério, faça as contas.

2. Scripts e ferramentas internas: A velocidade de inicialização faz os scripts parecerem instantâneos.

3. Projetos novos sem legacy: Começar com Bun é mais simples que começar com Node + npm + tsx + vitest + …

4. Serverless/Edge: Menos tempo de inicialização = menos cold starts = menos latência = usuários mais felizes.

5. Agora que a Anthropic está por trás: Isso não é pouca coisa. Eles têm grana, têm incentivos, e têm um produto (Claude Code) que depende do Bun ser bom.

Minha recomendação

Se você está começando um projeto novo e não tem restrições de equipe, teste o Bun. O pior que pode acontecer é você voltar pro Node, e terá aprendido algo.

Se você tem um projeto existente em produção, avalie primeiro no CI/CD. É onde mais se nota a diferença e onde há menos risco. Se bun install funciona bem com suas dependências, você já ganhou.

E se você é daqueles que gosta de viver no limite, coloque em produção e me conte como foi. Eu ainda não me atrevo, mas estou torcendo.

Recursos

• Documentação oficial
• Guia de migração do Node
• Awesome Bun - Lista curada de recursos

Conclusão

Bun é o que acontece quando alguém olha para o ecossistema do JavaScript e decide que podemos fazer melhor. E o preocupante é que… ele tem razão.

É o fim do Node? Provavelmente não. Node não vai desaparecer como não desapareceu Java quando saiu… bem, qualquer coisa. Mas sim é o primeiro concorrente sério em muito tempo.

E agora que a Anthropic está por trás, com seus bilhões de dólares e sua necessidade de que JavaScript voe, as coisas ficam interessantes.

Enquanto isso, vou continuar usando pnpm em produção. Mas meus scripts locais já rodam com Bun, e meu CI está em processo de migração. Aos poucos.

TL;DR: Bun é um runtime de JavaScript tudo-em-um (runtime + package manager + bundler + test runner) que é significativamente mais rápido que o Node. A Anthropic acabou de comprá-lo. Funciona com a maioria dos projetos TypeScript existentes. Teste no CI primeiro, que é onde mais se nota.

Este artigo foi escrito originalmente em espanhol e traduzido com a ajuda de IA.