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.

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

Por quê? Porque o Claude Code executa JavaScript a todo vapor, e cada milissegundo conta quando você tem milhões de usuários. Falando em português claro: 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 é o Bun e por que deveria te importar.

O que é o Bun (para quem vem do Node)

Bun é como se alguém tivesse olhado o ecossistema do Node e dissesse: “E se ao invés de ter quinze ferramentas fizermos uma que substitua todas?”

Onde antes você tinha:

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

Agora você tem:

bun           → tudo que está acima

É o patinete elétrico comparado ao 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:

Operação	Node + pnpm	Bun	Diferença
`install` (projeto médio)	~25s	~3s	8x mais rápido
Inicialização do runtime	~50ms	~5ms	10x mais rápido
Executar testes	baseline	2-3x mais rápido	Notável
Transpilar TypeScript	Precisa de ferramenta	Nativo	∞

Por que é tão rápido? Porque é 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 na 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)

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 o Node, instalar o Bun é um comando:

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

Ou se você usa macOS e Homebrew:

1
brew install oven-sh/bun/bun

Verifique se funciona:

1
bun --version

Criar um projeto novo

1
2
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

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

Execute:

1
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:

1
2
3
4
5
6
# Opção 1: Regenerar lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

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

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

O package.json não muda

1
2
3
4
5
6
7
{
  "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 Bun

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

1
2
3
4
5
6
7
// 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:

1
bun test

E se eu quiser continuar com Vitest?

Funciona perfeitamente. Bun pode executar Vitest como runtime:

1
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á

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

1
2
3
4
5
6
7
8
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, se sentirá em casa.

Benchmark de hello world

Na minha máquina (M1 Pro), um servidor 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 Express. Não, não é erro de digitação.

Variáveis de ambiente

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

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

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

Pronto. Funciona e ponto.

SQLite integrado

Isso explodiu minha cabeça. Bun vem com SQLite integrado:

1
2
3
4
5
6
7
8
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

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

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

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

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

Quando NÃO usar Bun

Porque nem tudo são flores:

Produção crítica onde você não pode experimentar: Bun é estável, mas Node tem 15 anos de bugs resolvidos.
Pacotes com bindings nativos muito específicos: Alguns precisam de trabalho extra.
Windows como plataforma principal: Funciona, mas o suporte de primeira classe é para macOS/Linux.
Sua equipe não quer aprender nada novo: Às vezes a melhor ferramenta é a que todo mundo sabe usar.

Quando SIM usar Bun

CI/CD: O tempo de install reduzido economiza dinheiro real. Sério, faça as contas.
Scripts e ferramentas internas: A velocidade de inicialização faz os scripts parecerem instantâneos.
Projetos novos sem legacy: Começar com Bun é mais simples que começar com Node + npm + tsx + vitest + …
Serverless/Edge: Menos tempo de inicialização = menos cold starts = menos latência = usuários mais felizes.
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 funcionar 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 com os dedos cruzados.

Recursos

Conclusão

Bun é o que acontece quando alguém olha o ecossistema 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 competidor 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 JavaScript tudo-em-um (runtime + package manager + bundler + test runner) que é significativamente mais rápido que Node. A Anthropic acabou de comprá-lo. Funciona com a maioria dos projetos TypeScript existentes. Teste primeiro no CI, que é onde mais se nota.

A notícia que ninguém viu chegando#

O que é o Bun (para quem vem do Node)#

Os números que importam#

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

Funciona bem#

Pode dar problemas#

Não funciona (ainda)#

Seu primeiro projeto com Bun#

Criar um projeto novo#

O arquivo que gera#

Migrando do pnpm#

O package.json não muda#

Testes: do Vitest para Bun#

E se eu quiser continuar com Vitest?#

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

Benchmark de hello world#

Variáveis de ambiente#

SQLite integrado#

O bundler#

Quando NÃO usar Bun#

Quando SIM usar Bun#

Minha recomendação#

Recursos#

Conclusão#