Publicado el 20 de agosto de 2026, Bun 1.4 supone la mayor ruptura de arquitectura del runtime hasta la fecha: el motor pasa de Zig a Rust y quince bibliotecas que el ecosistema JavaScript instalaba por separado se convierten en API nativas. El anuncio se apoya en tres ejes medidos: compatibilidad con Node.js, velocidad de instalación y uso de memoria.
Un motor reescrito en Rust
El cambio de Zig a Rust afecta al núcleo del runtime. No era teórico antes del anuncio: según los responsables, Claude Code funcionaba sobre el port de Rust desde hacía meses y Prisma lanzó Prisma Compute sobre él. Las mejoras anunciadas son concretas. El consumo de CPU en reposo de una aplicación «hola mundo» se divide por cinco. Los servidores HTTP reducen su memoria entre un 13 % y un 48 %: un servicio Fastify baja de 233 MB a 120 MB. El arranque es 2,5 veces más rápido en Windows (de 39 ms a 15,5 ms) y 2 veces más rápido en Linux (de 10,9 ms a 5,1 ms). Los binarios pierden hasta un 17 % de peso en Linux y Windows, y llega una compilación para Windows ARM64 de 75,1 MB frente a 90,2 MB en la 1.3.14.
Quince dependencias pasan a ser nativas
El cambio más visible en el día a día está en el package.json: tareas antes delegadas en paquetes de terceros ahora vienen con el runtime. La tabla resume las principales equivalencias.
| API nativa | Sustituye a |
|---|---|
Bun.Image | sharp |
Bun.WebView | puppeteer / playwright |
Bun.markdown | marked |
Bun.cron() | node-cron |
Bun.Terminal | node-pty |
Bun.JSON5 | json5 |
Bun.JSONL | ndjson |
Bun.XML | fast-xml-parser |
Bun.Archive | tar |
Bun.stringWidth / sliceAnsi / wrapAnsi | string-width, slice-ansi, wrap-ansi |
bun run --parallel | npm-run-all, concurrently |
En la práctica, un script de procesado de imágenes o una tarea programada ya no requiere una instalación externa.
// Redimensionner une image sans installer sharp
const thumb = await Bun.Image("photo.jpg")
.resize({ width: 640 })
.toBuffer({ format: "webp", quality: 80 });
// Planifier une tache sans node-cron
Bun.cron("0 3 * * *", () => {
console.log("Sauvegarde nocturne lancee");
});
Compatibilidad con Node.js y velocidad de instalación
En compatibilidad, la versión añade 1517 nuevas pruebas superadas de la suite de Node.js, hasta un total de 3743 archivos de test correctos, frente a 1450 en la 1.2.0. Los módulos node:quic, node:events, node:trace_events y node:sqlite superan el 100 % de las pruebas de Node. En instalación, bun install se anuncia quince veces más rápido que npm en el primer arranque sobre una aplicación Next.js de tipo T3 con unos 220 paquetes (1,41 s frente a 18,1 s). El nuevo «global virtual store», con el linker aislado, alcanza un factor siete en instalaciones en caliente de integración continua creando enlaces simbólicos en lugar de copiar los paquetes.
# Installation a froid : 15x plus rapide que npm sur ce projet
bun install
# Tests repartis sur 4 machines de CI, equilibres par duree
bun test --parallel --shard=1/4 --timings
# Deux scripts en parallele, sortie prefixee
bun run --parallel dev build
Quince dependencias menos en un
package.jsonson otras tantas de mantenimiento y auditoría menos.
Punto de atención. El soporte de HTTP/3 en Bun.serve() sigue siendo experimental, y la integración del React Compiler (anunciada veinte veces más rápida que el plugin de Babel) merece validarse proyecto a proyecto. La reescritura en Rust es transparente a nivel de API, pero conviene volver a ejecutar por completo una cadena de integración continua existente antes de cualquier paso a producción.
Lo que hay que recordar
Bun 1.4 desplaza la frontera entre el runtime y el ecosistema npm: menos paquetes que instalar, binarios más ligeros, menor huella de memoria y una compatibilidad con Node.js que progresa con claridad. Las cifras de arranque e instalación refuerzan sobre todo el argumento de herramientas e integración continua.
Adopté Bun primero donde el riesgo es bajo: scripts de build, tareas de CI, pequeñas utilidades. Ver Bun.Image o Bun.cron sustituir dependencias que arrastro desde hace años me convence más que cualquier gráfico de benchmark, porque reduce deuda real. Me frena una reserva: concentrar tantas funciones en un único runtime joven crea una dependencia fuerte de un solo proveedor. En un servicio crítico sigo validando la cadena de CI y la carga antes de cambiar, y conservo Node.js como plan de repliegue documentado. — Simon Janvier
Para profundizar
Notas de versión completas de Bun 1.4: bun.com/blog/bun-v1.4.
