Bun: El runtime que quiere jubilar a Node (y ahora tiene pasta para hacerlo)

La noticia que nadie vio venir

La semana pasada, mientras tú y yo estábamos tranquilamente peleándonos con el node_modules, Anthropic soltó una bomba: han comprado Bun.

Sí, la empresa detrás de Claude ha decidido que su futuro pasa por un runtime de JavaScript escrito en Zig por un tío que pensó «¿y si Node, pero rápido?». Claude Code acaba de alcanzar mil millones de dólares en revenue, y aparentemente lo primero que haces cuando te sobra la pasta es comprar herramientas de desarrollo.

¿Por qué? Pues porque Claude Code ejecuta JavaScript a cascoporro, y cada milisegundo cuenta cuando tienes millones de usuarios. Dicho en cristiano: si tu negocio depende de ejecutar código rápido, te compras el runtime más rápido.

Pero basta de cotilleo empresarial. Vamos a lo que te interesa: qué es Bun y por qué debería importarte.

Qué es Bun (para los que venimos de Node)

Bun es como si alguien hubiera mirado el ecosistema de Node y dijera: «¿Y si en lugar de tener quince herramientas hacemos una que las reemplace todas?»

Donde antes tenías:

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

Ahora tienes:

bun           → todo lo anterior

Es el patinete eléctrico frente al coche con remolque. Menos piezas, menos cosas que pueden fallar, y curiosamente más rápido.

Los números que importan

No me gusta hacer benchmarks porque siempre se pueden manipular. Pero estos números son tan brutales que merece la pena mencionarlos:

Operación	Node + pnpm	Bun	Diferencia
install (proyecto mediano)	~25s	~3s	8x más rápido
Arranque del runtime	~50ms	~5ms	10x más rápido
Ejecutar tests	baseline	2-3x más rápido	Notable
Transpilar TypeScript	Necesitas herramienta	Nativo	∞

¿Por qué es tan rápido? Porque está escrito en Zig en lugar de C++, y porque Jarred Sumner (el creador) es uno de esos programadores que optimiza código como hobby. El tipo trabajaba en Stripe y decidió que el problema más importante del mundo era que npm install tardaba demasiado.

Y, oye, a lo mejor tenía razón.

Lo que ya funciona (y lo que no)

Bun es compatible con la mayoría de APIs de Node. Si tu código usa fs, path, http, o cualquier módulo estándar, probablemente funcione sin cambios.

Funciona bien

• Next.js: Soporte oficial. bun run dev y listo.
• Express/Fastify: Sin problemas.
• La mayoría de paquetes npm: Bun lee package.json y node_modules igual que Node.
• TypeScript: Nativo, sin configuración.
• JSX: También nativo.

Puede dar problemas

• Paquetes con bindings nativos de Node: Algunos necesitan recompilarse.
• Código que depende de quirks específicos de V8: Bun usa JavaScriptCore (el motor de Safari).
• Algunas APIs de Node muy específicas: Workers, algunas partes de cluster.

No funciona (todavía)

• Windows: Funciona, pero con algunas limitaciones.
• Yarn PnP: No soportado.

Tu primer proyecto con Bun

Si ya tienes Node, instalar Bun es un comando:

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

O si eres de macOS y usas Homebrew:

brew install oven-sh/bun/bun

Verifica que funciona:

bun --version

Crear un proyecto nuevo

mkdir mi-proyecto && cd mi-proyecto
bun init

Esto te genera un package.json, un tsconfig.json, y un index.ts. Sin preguntas, sin wizards. Así me gusta.

El archivo que genera

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

Ejecútalo:

bun run index.ts

Sí, ejecuta TypeScript directamente. Sin transpilar. Sin ts-node. Sin nada.

Migrando desde pnpm

Si tienes un proyecto con pnpm, la migración es sorprendentemente sencilla:

# Opción 1: Regenerar lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

# Opción 2: Usar el lockfile existente (experimental)
bun install

Bun genera su propio bun.lockb (binario, más rápido de parsear). Puedes mantener ambos lockfiles durante la transición si trabajas en equipo y no todos han migrado.

El package.json no cambia

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

Sigues ejecutando bun run dev, bun run build, bun run test. Los scripts funcionan igual.

Tests: de Vitest a Bun

Bun tiene su propio test runner que es compatible con la API de 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);
});

Ejecuta con:

bun test

¿Y si quiero seguir con Vitest?

Funciona perfectamente. Bun puede ejecutar Vitest como runtime:

bun run vitest

Obtienes la velocidad de arranque de Bun con las features de Vitest. Lo mejor de ambos mundos.

El servidor HTTP más rápido que verás

Bun incluye un servidor HTTP que deja a Express llorando en una esquina:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hola desde Bun!");
  },
});

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

Usa la API estándar de fetch (Request/Response), así que si vienes de Cloudflare Workers o Deno, te sentirás como en casa.

Benchmark de hello world

En mi máquina (M1 Pro), un servidor de hello world:

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

Sí, diez veces más rápido que Express. No, no es un error tipográfico.

Variables de entorno

Bun carga .env automáticamente. Sin dotenv. Sin configuración.

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

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

Ya está. Funciona y punto.

SQLite integrado

Esto me voló la cabeza. Bun trae 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 o sql.js. Simplemente funciona.

El bundler

Bun también puede empaquetar tu código para producción:

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

Es más rápido que esbuild (que ya era ridículamente rápido). Para la mayoría de proyectos, genera bundles equivalentes.

Si necesitas algo más sofisticado (code splitting, tree shaking avanzado), probablemente sigas necesitando Vite o webpack. Pero para muchos casos, esto es suficiente.

Cuándo NO usar Bun

Porque no todo es arcoíris y unicornios:

1. Producción crítica donde no puedes experimentar: Bun es estable, pero Node tiene 15 años de bugs resueltos.

2. Paquetes con bindings nativos muy específicos: Algunos necesitan trabajo extra.

3. Windows como plataforma principal: Funciona, pero el soporte de primera clase es para macOS/Linux.

4. Tu equipo no quiere aprender nada nuevo: A veces la mejor herramienta es la que todo el mundo sabe usar.

Cuándo SÍ usar Bun

1. CI/CD: El tiempo de install reducido ahorra dinero real. En serio, haz las cuentas.

2. Scripts y herramientas internas: La velocidad de arranque hace que los scripts se sientan instantáneos.

3. Proyectos nuevos sin legacy: Empezar con Bun es más simple que empezar con Node + npm + tsx + vitest + …

4. Serverless/Edge: Menos tiempo de arranque = menos cold starts = menos latencia = usuarios más contentos.

5. Ahora que Anthropic lo respalda: Esto no es poca cosa. Tienen pasta, tienen incentivos, y tienen un producto (Claude Code) que depende de que Bun sea bueno.

Mi recomendación

Si estás empezando un proyecto nuevo y no tienes restricciones de equipo, prueba Bun. Lo peor que puede pasar es que vuelvas a Node, y habrás aprendido algo.

Si tienes un proyecto existente en producción, evalúa primero en CI/CD. Es donde más se nota la diferencia y donde menos riesgo hay. Si bun install funciona bien con tus dependencias, ya has ganado.

Y si eres de los que les gusta vivir al límite, mételo en producción y cuéntame qué tal. Yo aún no me atrevo, pero tengo los dedos cruzados.

Recursos

• Documentación oficial
• Guía de migración desde Node
• Awesome Bun – Lista curada de recursos

Conclusión

Bun es lo que pasa cuando alguien mira el ecosistema de JavaScript y decide que podemos hacerlo mejor. Y lo preocupante es que… tiene razón.

¿Es el fin de Node? Probablemente no. Node no va a desaparecer como no desapareció Java cuando salió… bueno, cualquier cosa. Pero sí que es el primer competidor serio en mucho tiempo.

Y ahora que Anthropic está detrás, con sus mil millones de dólares y su necesidad de que JavaScript vuele, las cosas se ponen interesantes.

Mientras tanto, yo voy a seguir usando pnpm en producción. Pero mis scripts locales ya corren con Bun, y mi CI está en proceso de migración. Poco a poco.

---

TL;DR: Bun es un runtime de JavaScript todo-en-uno (runtime + package manager + bundler + test runner) que es significativamente más rápido que Node. Anthropic lo acaba de comprar. Funciona con la mayoría de proyectos TypeScript existentes. Pruébalo en CI primero, que es donde más se nota.

---

Read this article in English.