Bun es un runtime de JavaScript y TypeScript construido sobre JavaScriptCore, el motor que usa Safari. Salió en versión 1.0 en septiembre de 2023 con una promesa clara: sustituir Node.js, npm, Jest y esbuild con una sola herramienta. Runtime, bundler, test runner y gestor de paquetes, todo junto.
Lo más visible frente a Node.js sigue siendo la velocidad de instalación de paquetes: entre 7 y 10 veces más rápido que npm en proyectos medianos. Pero en 2025 ocurrió algo más relevante a nivel empresa: Bun se unió a Anthropic, la compañía detrás de Claude. El equipo sigue siendo el mismo y el proyecto sigue siendo open source, pero ahora tiene el respaldo de una de las empresas más activas en IA.
En 2026, Bun ya no es una apuesta arriesgada. Las versiones 1.3.x han añadido APIs que antes requerían instalar paquetes externos, y la compatibilidad con el ecosistema npm es bastante amplia para la mayoría de proyectos.
Bun 1.3.10 (febrero 2026): decoradores TC39 y Windows ARM64
Esta versión llegó con dos cosas que llevaban tiempo pidiendo los usuarios.
Decoradores según el estándar TC39
Bun ya soporta los decoradores del estándar TC39, que son los que Chrome implementó a partir de la versión 130 y los que TypeScript 5.x también adopta. No los decoradores experimentales de TypeScript legacy con experimentalDecorators: true en el tsconfig, sino el estándar real.
Si usas frameworks que dependen de decoradores, como NestJS o algunas versiones de Angular, esta es la actualización que necesitabas para poder migrar sin parches.
Windows ARM64
Bun ya corre de forma nativa en Windows ARM64, lo que incluye Surface Pro X, los Copilot+ PCs de Microsoft y cualquier máquina con chip ARM bajo Windows. Hasta ahora había que usar emulación x86, con la penalización de rendimiento que eso supone.
--compile --target=browser
Con este flag puedes generar un fichero HTML autocontenido que lleva el bundle de tu aplicación embebido. Sin servidor, sin proceso de despliegue complejo: un solo archivo que puedes abrir en el navegador o distribuir directamente.
bun build --compile --target=browser src/index.ts --outfile app.htmlBun 1.3.12 (abril 2026): Bun.WebView y Bun.cron()
Esta fue probablemente la versión más llamativa de la serie 1.3. Dos APIs nuevas que antes obligaban a instalar dependencias externas.
Bun.WebView
Bun.WebView abre una ventana de navegador headless desde tu script de Bun. Sirve para automatización, scraping, testing de interfaces de usuario o cualquier tarea que necesite un contexto de navegador real sin levantar Puppeteer ni Playwright con todo lo que arrastran.
const view = new Bun.WebView({ url: "https://example.com" });
await view.evaluate(() => document.title);
view.close();Útil sobre todo para scripts de automatización puntuales donde no quieres gestionar un proceso de Chrome aparte.
Bun.cron()
Bun.cron() permite programar tareas dentro del propio proceso de Bun, con sintaxis cron estándar, sin tocar el cron del sistema ni instalar node-cron ni cron-job.
Bun.cron("0 * * * *", () => {
console.log("Se ejecuta cada hora");
});Para scripts de servidor sencillos, esto elimina una dependencia entera del package.json.
Menos memoria en streaming
Esta versión también trajo mejoras internas en el manejo de streams de datos. Según los benchmarks del equipo, Bun consume hasta 17 veces menos memoria que Node.js en escenarios de streaming intensivo. Es un dato que hay que tomar con contexto, porque depende mucho del caso de uso concreto, pero la dirección es clara.
Bun 1.3.13 (abril 2026): tests paralelos y por fragmentos
El test runner de Bun recibió tres flags nuevos que lo hacen más útil en pipelines de CI.
--parallel
Corre los tests en múltiples workers en paralelo. En suites grandes, la reducción de tiempo es notable desde la primera ejecución.
bun test --parallel--shard
Divide la suite en fragmentos para repartir entre varias máquinas. Si tienes tres runners en CI, cada uno ejecuta un tercio de los tests.
# Máquina 1
bun test --shard=1/3
# Máquina 2
bun test --shard=2/3
# Máquina 3
bun test --shard=3/3--changed
Solo ejecuta los tests que tocan ficheros modificados desde el último commit de git. Para proyectos grandes donde la suite completa tarda varios minutos, este flag puede ahorrarte mucho tiempo en el día a día.
bun test --changedBun 1.3.14 (mayo 2026): Bun.Image y HTTP/3
La versión más reciente de la serie añade procesamiento de imágenes nativo y soporte experimental de HTTP/3.
Bun.Image
Procesar imágenes en Node.js siempre ha requerido instalar sharp o jimp, que a su vez dependen de libvips o de código nativo compilado. Con Bun.Image ya no necesitas nada de eso.
const img = await Bun.Image.decode(Bun.file("foto.jpg"));
const resized = img.resize(800, 600);
await resized.encode("webp").write("foto.webp");
// Convertir a AVIF
await resized.encode("avif").write("foto.avif");Soporta los formatos más comunes: JPEG, PNG, WebP y AVIF. Para proyectos donde el procesamiento de imágenes era el único motivo para tener sharp como dependencia, esto simplifica bastante el setup.
HTTP/3 y QUIC en fetch()
El fetch() de Bun ahora tiene soporte experimental de HTTP/3 sobre QUIC. El protocolo mejora la latencia en conexiones con pérdida de paquetes y elimina el problema del head-of-line blocking de HTTP/2.
const res = await fetch("https://example.com", {
// HTTP/3 se negocia automáticamente si el servidor lo soporta
});Por ahora es experimental, así que no lo uses en producción sin probar antes que el servidor de destino lo soporta correctamente.
Instalaciones 7 veces más rápidas que npm
Bun 1.3.14 también incluye mejoras en el gestor de paquetes. En benchmarks con proyectos reales, bun install es unas 7 veces más rápido que npm install con caché fría. La diferencia baja con caché caliente, pero sigue siendo significativa.
Compatibilidad con Node.js: ¿dónde están los límites?
La mayoría de paquetes de npm funcionan en Bun sin cambios. Para proyectos nuevos con dependencias estándar, la migración suele ser directa.
Donde aparecen problemas es con los módulos nativos, los archivos .node compilados para Node.js. Bun tiene soporte parcial: algunos funcionan, otros no. Si tu proyecto depende de módulos nativos específicos, tienes que probar antes de comprometerte con la migración.
También hay diferencias sutiles en algunos comportamientos de streams y eventos que en Node.js tienen décadas de historial y edge cases resueltos. No es que Bun esté mal, es que hay comportamientos donde la compatibilidad no es del 100%.
Para proyectos nuevos donde controlas las dependencias, Bun es una opción real. Para proyectos grandes con muchas dependencias nativas o código muy acoplado al API de Node.js, toca evaluar caso a caso.
bun --hot y bun --watch en desarrollo
Dos flags que mejoran el flujo de desarrollo sin instalar nada adicional.
- bun --hot: recarga módulos en caliente sin reiniciar el proceso. El estado en memoria se mantiene entre recargas, lo que es útil para servidores donde no quieres perder conexiones activas.
- bun --watch: reinicio completo al detectar cambios en el sistema de archivos. Más predecible que
--hotpara casos donde el estado puede volverse inconsistente.
# Servidor HTTP con recarga de módulos en caliente
bun --hot server.ts
# Script con reinicio completo al guardar
bun --watch script.tsAmbos son notablemente más rápidos que la combinación típica de nodemon + ts-node que se usa en proyectos Node.js. El tiempo de reinicio pasa de segundos a milisegundos.
Cuándo usar Bun sobre Node.js en 2026
No hay una respuesta única, pero hay algunos casos donde la decisión es bastante clara.
- Scripts de build y CI: Bun es más rápido casi siempre. La instalación de dependencias y la ejecución de scripts de build mejoran sin cambiar nada más.
- Proyectos nuevos con TypeScript: Bun ejecuta TypeScript directamente sin
ts-nodeni configuración extra. Si empiezas desde cero, el setup es más simple. - Cuando quieres menos dependencias: Bun.Image, Bun.cron() y Bun.WebView eliminan paquetes enteros del
package.json. Menos dependencias son menos superficie de ataque y menos actualizaciones que gestionar. - Producción en servidores: Bun es estable pero tiene menos historial que Node.js. Si el proyecto es crítico y usa módulos nativos, Node.js sigue siendo la opción más conservadora.
Si ya tienes un proyecto en Node.js que funciona bien, no hay motivo urgente para migrar. Pero si estás empezando algo nuevo o tienes scripts de build lentos, vale la pena probarlo.
Para comparar con lo que está haciendo Node.js en paralelo, puedes ver Node.js 26: el runtime que compite con Bun. Y si quieres entender mejor el contexto general de los runtimes JS modernos, JavaScript y sus runtimes en 2026 lo explica bien.
Imagen: Pexels / Pixabay