Bun y la ambición en el software: por qué apuntar más alto

¿Alguna vez te quedaste mirando el npm install correr y pensaste "así es nomás"? Esa resignación es el tema de un texto de Dan Luu, We should be more ambitious with the software we build. Para mí, Bun es el mejor ejemplo reciente de lo que pasa cuando alguien se niega a aceptar el "así es nomás". En este artículo junto las dos cosas: la provocación de Dan Luu y lo que Bun enseña, en la práctica, sobre ambición técnica.

Qué está diciendo Dan Luu

Dan Luu escribe hace años sobre una molestia que todo dev conoce. Las computadoras se volvieron absurdamente más rápidas, pero el software no acompañó. En textos antiguos midió la latencia del teclado entre máquinas de 1977 y de 2017, y la cuenta no cerraba a favor de las nuevas. También escribió sobre la hinchazón de la web: páginas que pesan megabytes para mostrar tres párrafos.

La idea central ahora es simple. Nos acostumbramos a apuntar bajo. Aceptamos herramientas lentas, apps pesadas y builds de cinco minutos porque "todo el mundo los usa". Y cuando alguien sugiere rehacer algo desde cero, la respuesta estándar es "no reinventes la rueda".

Pero a veces la rueda es cuadrada.

Por qué Bun es el ejemplo perfecto de ambición

¿Te acuerdas del ecosistema JavaScript en 2021? Necesitabas Node para ejecutar, npm o Yarn o pnpm para instalar, Webpack o esbuild para empaquetar, Jest o Vitest para testear, ts-node o tsx para correr TypeScript, dotenv para leer el .env. Cada pieza con su config, sus bugs y sus peleas de versiones.

Jarred Sumner miró todo eso y decidió hacerlo todo de una vez. Runtime, gestor de paquetes, bundler y test runner en un solo binario, escrito en Zig y corriendo sobre JavaScriptCore. En su momento, mucha gente pensó que era una locura. ¿Una persona (después un equipo pequeño) queriendo reemplazar el trabajo de miles de mantenedores?

El resultado ya lo conoces. El bun install termina antes de que cambies de pestaña. TypeScript corre directo, sin paso de compilación. Y el proyecto se volvió lo bastante serio como para que Anthropic comprara la empresa a fines de 2025, porque Claude Code corre sobre él.

A veces la rueda es cuadrada, y reinventarla es la única opción honesta.

El punto no es que Bun sea perfecto. No lo es. El punto es que solo existe porque alguien consideró inaceptable lo que todos consideraban normal.

Qué cambia en el código cuando la herramienta es ambiciosa

La ambición de una herramienta se convierte en simplicidad en tu proyecto. Mira un endpoint que lee de PostgreSQL usando solo lo que viene en 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 });
    },
  },
});

Fíjate en lo que no hay aquí. No hay Express. No hay pg. No hay dotenv, porque Bun lee el .env solo y el sql toma la DATABASE_URL de ahí. El package.json de este servicio puede tener cero dependencias de runtime.

Y el test viene incluido:

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

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

bun test y listo. Sin preset, sin transformer, sin ese jest.config.js que nadie recuerda por qué existe.

En la práctica, lo que siento en el día a día:

• Menos dependencias significa menos alertas de seguridad en Dependabot.
• Menos config significa un onboarding más rápido para quien llega al proyecto.
• Feedback más rápido significa que corro los tests de verdad, en vez de dejarlos para el CI.

Este último es el más subestimado. Una herramienta lenta no solo te quita tiempo. Cambia tu comportamiento. Si el test tarda 40 segundos, lo corres menos. Si tarda 2, lo corres todo el tiempo.

"¿Pero reescribir desde cero no es siempre un error?"

Esa es la objeción clásica, y tiene fundamento. Hay un texto famoso de Joel Spolsky que dice que reescribir software desde cero es el peor error estratégico que puede cometer una empresa. Hablaba de Netscape, y en ese caso tenía razón.

Pero el consejo se volvió dogma. Y el dogma es pereza disfrazada de sabiduría.

La diferencia está en qué estás reescribiendo y por qué. Netscape reescribió un producto que funcionaba, perdió años y perdió el mercado. Bun no reescribió Node por capricho. Atacó un problema medido: tiempo de instalación, tiempo de arranque, cantidad de herramientas en la cadena. Cada decisión tenía un número detrás.

Ambición no es "voy a rehacer todo porque el código está feo". Es mirar una métrica que todos aceptan y preguntar si tiene que ser así. A veces la respuesta es sí. A veces es "se puede hacer diez veces mejor".

Y vale la advertencia honesta: Bun todavía tiene asperezas. Algunas APIs de Node se comportan distinto, alguna que otra lib nativa da trabajo, y en producción crítica todavía pruebo bien antes de cambiar. La ambición cobra un precio en madurez, y quien adopta temprano paga parte de esa cuenta.

Cómo llevar esa ambición a tu proyecto

No necesitas escribir un runtime en Zig. La ambición que defiende Dan Luu cabe en decisiones pequeñas del día a día. Algunas que aplico:

1. Mide antes de aceptar. ¿Cuánto tarda tu build? ¿Tu cold start? ¿La primera carga de la página en 4G? Si no sabes el número, no sabes si está mal.
2. Cuestiona cada dependencia. Antes de hacer bun add, pregúntate si la plataforma ya lo resuelve. fetch, crypto.randomUUID(), Intl, structuredClone: muchas libs populares se volvieron pura nostalgia.
3. Trata la lentitud como un bug. Si una pantalla tarda 3 segundos, abre un issue. No es "mejora futura", es un defecto.
4. Elige herramientas que acorten la cadena. Cambiar cuatro herramientas por una tiene valor aunque ninguna sea mala por sí sola.

Una prueba rápida que me gusta: corre time bun install y time npm install en un proyecto limpio tuyo. No por el marcador, sino para sentir en carne propia la diferencia entre "aceptable" y "nadie había intentado mejorarlo".

Mi opinión: el problema rara vez es técnico

Lo que más me atrapó del texto de Dan Luu es que la barrera casi nunca es el hardware ni el lenguaje. Es la expectativa. Miramos una app de chat que consume 1 GB de RAM y nos parece normal, porque la anterior también lo hacía.

Bun es un recordatorio de que una persona terca con un problema bien medido puede mover un ecosistema entero. Eso no quiere decir que debas salir a migrar todo mañana. Quiere decir que vale la pena desconfiar cada vez que te descubres diciendo "así es nomás".

Prefiero equivocarme por exceso de ambición que pasar la carrera optimizando la velocidad con la que acepto herramientas malas. Si quieres ver dónde he aplicado esto, incluso con Bun en producción, échale un vistazo a mis proyectos.

¿Alguna vez miraste el `npm install` corriendo y pensaste "así es nomás"?

Dan Luu tiene un texto que me atrapó: nos acostumbramos a apuntar bajo. Aceptamos builds lentos, apps pesadas y diez herramientas para hacer lo básico.

Bun muestra lo contrario. Una persona terca juntó runtime, bundler, test runner y gestor de paquetes en un solo binario. Mucha gente pensó que era una locura.

Hoy levanto un endpoint con PostgreSQL sin Express, sin pg y sin dotenv. Un test que corre en 2 segundos es un test que corro todo el tiempo.

"No reinventes la rueda" se volvió dogma. A veces la rueda es cuadrada.

Escribí sobre ambición técnica, las asperezas de Bun y cómo llevar esto al día a día. Link en los comentarios.

#Bun #JavaScript #TypeScript #DesarrolloDeSoftware #DevExperience