Bun e a ambição no software: por que mirar mais alto

Você já ficou olhando o npm install rodar e pensou "é assim mesmo"? Essa resignação é o assunto de um texto do Dan Luu, We should be more ambitious with the software we build. Para mim, o Bun é o melhor exemplo recente do que acontece quando alguém se recusa a aceitar o "é assim mesmo". Neste artigo eu junto as duas coisas: a provocação do Dan Luu e o que o Bun ensina, na prática, sobre ambição técnica.

O que o Dan Luu está dizendo

O Dan Luu escreve faz anos sobre um incômodo que todo dev conhece. Os computadores ficaram absurdamente mais rápidos, mas o software não acompanhou. Em textos antigos ele mediu a latência de teclado entre máquinas de 1977 e de 2017, e a conta não fechava a favor das novas. Também escreveu sobre o inchaço da web: página que pesa megabytes para mostrar três parágrafos.

A ideia central agora é simples. A gente se acostumou a mirar baixo. Aceitamos ferramenta lenta, app pesado e build de cinco minutos porque "todo mundo usa". E quando alguém sugere refazer algo do zero, a resposta padrão é "não reinvente a roda".

Só que às vezes a roda está quadrada.

Por que o Bun é o exemplo perfeito de ambição

Lembra do ecossistema JavaScript em 2021? Você precisava de Node para rodar, npm ou Yarn ou pnpm para instalar, Webpack ou esbuild para empacotar, Jest ou Vitest para testar, ts-node ou tsx para rodar TypeScript, dotenv para ler .env. Cada peça com sua config, seus bugs e suas brigas de versão.

O Jarred Sumner olhou para isso e decidiu fazer tudo de uma vez. Runtime, gerenciador de pacotes, bundler e test runner num binário só, escrito em Zig e rodando sobre o JavaScriptCore. Na época, muita gente achou loucura. Uma pessoa (depois um time pequeno) querendo substituir o trabalho de milhares de mantenedores?

O resultado você conhece. O bun install termina antes de você trocar de aba. TypeScript roda direto, sem passo de compilação. E o projeto ficou sério o bastante para a Anthropic comprar a empresa no fim de 2025, porque o Claude Code roda em cima dele.

Às vezes a roda está quadrada, e reinventar é a única opção honesta.

O ponto não é que o Bun é perfeito. Não é. O ponto é que ele só existe porque alguém achou inaceitável o que todo mundo achava normal.

O que muda no código quando a ferramenta é ambiciosa

Ambição de ferramenta vira simplicidade no seu projeto. Olha um endpoint que lê do PostgreSQL usando só o que vem no Bun:

import { serve, sql } from "bun";

serve({
  port: 3000,
  routes: {
    "/api/users/:id": async (req) => {
      const [user] = await sql`select id, name from users where id = ${req.params.id}`;
      return user ? Response.json(user) : new Response("Not found", { status: 404 });
    },
  },
});

Repara no que não tem aqui. Não tem Express. Não tem pg. Não tem dotenv, porque o Bun lê o .env sozinho e o sql pega a DATABASE_URL dele. O package.json desse serviço pode ter zero dependências de runtime.

E o teste vem junto:

import { test, expect } from "bun:test";

test("soma", () => {
  expect(1 + 1).toBe(2);
});

bun test e pronto. Sem preset, sem transformer, sem aquele jest.config.js que ninguém lembra por que existe.

Na prática, o que eu sinto no dia a dia:

• Menos dependências significa menos alerta de segurança no Dependabot.
• Menos config significa onboarding mais rápido para quem chega no projeto.
• Feedback mais rápido significa que eu rodo os testes de verdade, em vez de deixar para o CI.

Esse último é o mais subestimado. Ferramenta lenta não só gasta seu tempo. Ela muda seu comportamento. Se o teste demora 40 segundos, você roda menos. Se demora 2, você roda o tempo todo.

"Mas reescrever do zero não é sempre um erro?"

Essa é a objeção clássica, e ela tem fundamento. Tem um texto famoso do Joel Spolsky dizendo que reescrever software do zero é o pior erro estratégico que uma empresa pode cometer. Ele estava falando do Netscape, e tinha razão naquele caso.

Só que o conselho virou dogma. E dogma é preguiça disfarçada de sabedoria.

A diferença está no que você está reescrevendo e por quê. O Netscape reescreveu um produto que funcionava, perdeu anos e o mercado. O Bun não reescreveu o Node por capricho. Ele atacou um problema medido: tempo de instalação, tempo de startup, número de ferramentas na cadeia. Cada decisão tinha um número por trás.

Ambição não é "vou refazer tudo porque o código está feio". É olhar uma métrica que todo mundo aceita e perguntar se precisa ser assim. Às vezes a resposta é sim. Às vezes é "dá para ser dez vezes melhor".

E vale o aviso honesto: o Bun ainda tem arestas. Algumas APIs do Node têm comportamento diferente, uma ou outra lib nativa dá trabalho, e em produção crítica eu ainda testo bem antes de trocar. Ambição cobra um preço em maturidade, e quem adota cedo paga parte dessa conta.

Como trazer essa ambição para o seu projeto

Você não precisa escrever um runtime em Zig. A ambição que o Dan Luu defende cabe em decisões pequenas do dia a dia. Algumas que eu aplico:

1. Meça antes de aceitar. Quanto tempo leva seu build? Seu cold start? O primeiro carregamento da página no 4G? Se você não sabe o número, você não sabe se está ruim.
2. Questione cada dependência. Antes de dar bun add, pergunte se a plataforma já resolve. fetch, crypto.randomUUID(), Intl, structuredClone: muita lib popular virou só nostalgia.
3. Trate lentidão como bug. Se uma tela demora 3 segundos, abra uma issue. Não é "melhoria futura", é defeito.
4. Escolha ferramentas que reduzem a cadeia. Trocar quatro ferramentas por uma tem valor mesmo que nenhuma delas seja ruim sozinha.

Um teste rápido que eu gosto: rode time bun install e time npm install num projeto limpo seu. Não pelo placar, mas para sentir na pele a diferença entre "aceitável" e "ninguém tinha tentado melhorar".

Minha opinião: o problema raramente é técnico

O que mais me pegou no texto do Dan Luu é que a barreira quase nunca é o hardware ou a linguagem. É a expectativa. A gente olha para um app de chat que consome 1 GB de RAM e acha normal, porque o anterior também consumia.

O Bun é um lembrete de que uma pessoa teimosa com um problema bem medido consegue mexer num ecossistema inteiro. Isso não quer dizer que você deva sair migrando tudo amanhã. Quer dizer que vale desconfiar toda vez que você se pega dizendo "é assim mesmo".

Eu prefiro errar por excesso de ambição do que passar a carreira otimizando a velocidade com que aceito ferramenta ruim. Se quiser ver onde eu tenho aplicado isso, inclusive com Bun em produção, dá uma olhada nos meus projetos.

Já pegou o `npm install` rodando e pensou "é assim mesmo"?

O Dan Luu tem um texto que me pegou: a gente se acostumou a mirar baixo. Aceita build lento, app pesado e dez ferramentas pra fazer o básico.

O Bun mostra o contrário. Uma pessoa teimosa juntou runtime, bundler, test runner e gerenciador de pacotes num binário só. Muita gente achou loucura.

Hoje eu subo um endpoint com PostgreSQL sem Express, sem pg e sem dotenv. Teste que roda em 2 segundos é teste que eu rodo toda hora.

"Não reinvente a roda" virou dogma. Às vezes a roda está quadrada.

Escrevi sobre ambição técnica, as arestas do Bun e como trazer isso pro dia a dia. Link nos comentários.

#Bun #JavaScript #TypeScript #DesenvolvimentoDeSoftware #DevExperience