Node.js y Bun como runtimes modernos

Panorama de runtimes de JavaScript fuera del navegador

Durante muchos años, ejecutar JavaScript fuera del navegador significaba usar Node.js. Hoy el ecosistema se ha ampliado y conviven varios runtimes con filosofías distintas. El más consolidado sigue siendo Node.js, con soporte empresarial, versiones LTS y un catálogo de paquetes en npm que supera los dos millones de módulos. La aparición de Bun ha cambiado el panorama con tiempos de arranque muy inferiores y un conjunto de herramientas integradas.

Un runtime proporciona el motor que interpreta el código, las APIs para interactuar con el sistema de archivos, la red o los procesos, y un gestor de módulos capaz de cargar dependencias externas. Elegir runtime condiciona qué APIs nativas puedes usar, cómo se instalan las dependencias y qué flags están disponibles para optimizar la ejecución.

La recomendación sensata para 2026 es Node.js LTS como base estable en producción y Bun para prototipos, scripts internos y entornos donde el tiempo de arranque pese.

Diferencias clave entre Node.js y Bun

Ambos ejecutan código JavaScript moderno, soportan TypeScript sin transpilación manual y entienden ESM. Pero divergen en varios puntos importantes.

Node.js usa el motor V8 de Chromium y está escrito en C++. Sigue un ciclo de versiones LTS cada año par, con dos años adicionales de mantenimiento. Su gestor de paquetes principal es npm, aunque pnpm y yarn son alternativas extendidas. El test runner nativo llegó como parte del módulo node:test, integrado desde la versión 20.

Bun usa el motor JavaScriptCore de Safari y está escrito en Zig. Incluye gestor de paquetes propio (bun install), un bundler, un test runner (bun test) y un transpilador TypeScript integrado. La instalación de dependencias con bun install suele ser entre cinco y treinta veces más rápida que npm.

graph TD
    A[Cdigo JavaScript o TypeScript] --> B{Runtime elegido}
    B -->|Estabilidad y ecosistema| C[Node.js LTS]
    B -->|Velocidad y all-in-one| D[Bun]
    C --> E[V8 + libuv]
    D --> F[JavaScriptCore + Zig]
    E --> G[npm / pnpm]
    F --> H[bun install integrado]

Instalar y gestionar versiones de Node.js

La forma recomendada de instalar Node.js no es el instalador gráfico, sino un gestor de versiones. En Windows, macOS y Linux, la herramienta más utilizada hoy es fnm (Fast Node Manager), escrita en Rust, con instalación prácticamente instantánea. La alternativa tradicional es nvm.

# Instalar fnm en macOS y Linux
curl -fsSL https://fnm.vercel.app/install | bash

# Instalar fnm en Windows con Scoop
scoop install fnm

Tras instalar fnm, activar una versión concreta es cuestión de dos comandos. Las versiones LTS tienen soporte extendido, mientras que las Current incluyen las últimas novedades sin garantía de estabilidad prolongada.

fnm install --lts
fnm use lts-latest
node --version

Un archivo .nvmrc o .node-version en la raíz del proyecto fija la versión requerida. Al entrar en el directorio, fnm puede cambiar automáticamente a la versión correcta si configuras el hook del shell.

Usar un gestor de versiones te evita permisos de administrador y conflictos entre proyectos con requisitos distintos.

Ejecutar scripts y el flag watch

Ejecutar un archivo JavaScript con Node es directo: node script.js. La novedad más útil para desarrollo es el flag --watch, que observa los cambios del archivo y reinicia el proceso sin dependencias externas como nodemon.

node --watch servidor.js

Otro flag frecuente es --env-file, que carga variables de entorno desde un archivo .env sin usar la librería dotenv. Junto con --watch-path, permite restringir qué carpetas se vigilan.

node --env-file=.env --watch servidor.js

Para proyectos TypeScript pequeños, Node.js incluye soporte experimental de TypeScript mediante el flag --experimental-strip-types, que permite ejecutar archivos .ts sin transpilación previa siempre que no uses sintaxis específica de TypeScript en tiempo de ejecución.

Instalar y usar Bun

Bun se instala con un único comando y no necesita gestor de versiones externo, aunque existe bun upgrade para actualizar a la última versión.

# macOS y Linux
curl -fsSL https://bun.sh/install | bash

# Windows con PowerShell
powershell -c "irm bun.sh/install.ps1 | iex"

Una vez instalado, ejecutar un script es análogo a Node: bun script.js. La diferencia está en el arranque, más rápido, y en el soporte nativo de TypeScript sin flags. Bun también entiende JSX por defecto.

bun install          # Instala dependencias de package.json
bun run dev          # Ejecuta el script "dev" definido
bun test             # Ejecuta los tests del proyecto
bun add zod          # Anade una dependencia

El comando bun --hot habilita la recarga en caliente preservando estado en memoria, algo útil para servidores en desarrollo. La diferencia con --watch es que --hot intenta mantener conexiones abiertas cuando es posible.

Compatibilidad con APIs de Node.js

Bun implementa la mayoría de APIs de Node.js, incluyendo fs, path, http, crypto o child_process. Esto permite ejecutar muchos proyectos existentes sin modificaciones. La compatibilidad no es total: algunas APIs internas, ciertos flags y algunos módulos nativos pueden comportarse de forma diferente.

// Funciona igual en Node.js y Bun
import { readFile } from "node:fs/promises";

const contenido = await readFile("datos.json", "utf-8");
const parsed = JSON.parse(contenido);
console.log(parsed);

Bun anade APIs propias bajo el prefijo Bun.*, como Bun.file() para lectura eficiente de ficheros o Bun.serve() para montar un servidor HTTP con una API más simple que la de Node.

Servidor HTTP mínimo en cada runtime

Para apreciar las diferencias prácticas, comparemos un servidor HTTP básico en ambos runtimes. En Node.js usamos el módulo node:http, parte de la biblioteca estándar.

// servidor-node.js
import { createServer } from "node:http";

const servidor = createServer((req, res) => {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ mensaje: "Hola desde Node.js" }));
});

servidor.listen(3000, () => {
    console.log("Servidor escuchando en http://localhost:3000");
});

En Bun, la API Bun.serve() es más concisa y utiliza el estándar Fetch API (Request y Response) en lugar de los objetos propios de Node.

// servidor-bun.js
Bun.serve({
    port: 3000,
    fetch(req) {
        return new Response(JSON.stringify({ mensaje: "Hola desde Bun" }), {
            headers: { "Content-Type": "application/json" }
        });
    }
});

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

Ambos enfoques son equivalentes en funcionalidad, pero la versión de Bun usa objetos Web estándar. Si migras más tarde a Cloudflare Workers, Deno o cualquier entorno que hable Fetch API, el código de Bun se parece más al destino final.

Elegir entre Node y Bun no es una decisión definitiva. Muchos equipos usan Bun en desarrollo por velocidad y despliegan en Node.js por madurez operativa.

Benchmarks y contexto realista

Los benchmarks publicados por Bun muestran tiempos de arranque muy inferiores y un rendimiento de request por segundo elevado. Estos números son reales pero dependen del caso. En aplicaciones con mucha I/O encadenada o uso intensivo de dependencias nativas, la diferencia se reduce.

El consejo profesional es medir con tu propia carga antes de migrar. Herramientas como autocannon o wrk permiten comparar escenarios reales en minutos.

# Ejemplo con autocannon
npx autocannon -d 10 -c 100 http://localhost:3000

La conclusión práctica: Node.js sigue siendo el estándar de facto para backend serio; Bun es una excelente elección para scripts, CLIs, pruebas locales y servicios simples, con un futuro prometedor a medida que su estabilidad aumenta.