Breve historia: de los scripts globales a Vite

La historia de las herramientas de build no es una sucesión de modas, sino una cadena de respuestas a dolores concretos. Cada salto —de los scripts globales a los módulos, de las task runners a los bundlers, de los bundlers a los dev servers— resolvió un problema real que el eslabón anterior no podía. Entender por qué apareció cada pieza vale mucho más que memorizar sus nombres, porque los nombres cambian y los problemas se repiten.

Del ámbito global a los módulos

El punto de partida fue el caos que ya conoces: muchos <script> colgando del objeto global, orden frágil y colisiones silenciosas. La primera defensa seria llegó del servidor. En 2009, Node adoptó CommonJS: un sistema de módulos con require y module.exports, síncrono porque en un servidor los archivos están en el disco local y leerlos es instantáneo. Sobre CommonJS creció npm, y con él la idea de que el código se distribuye en paquetes.

// CommonJS (Node, 2009): sincrono, require y module.exports
const fs = require("fs");
module.exports = function leer(ruta) {
  return fs.readFileSync(ruta, "utf8");
};

El navegador no podía copiar ese modelo: un require síncrono que fuera a buscar un archivo por la red bloquearía la interfaz. Lo que en el servidor era instantáneo, en el cliente habría congelado la página en cada importación.

La respuesta fue AMD (Asynchronous Module Definition) y su implementación estrella, RequireJS, que declaraba las dependencias por adelantado y las cargaba de forma asíncrona con una función define. El precio era una sintaxis envolvente y verbosa.

// AMD (RequireJS): declara las dependencias antes de usarlas y las carga sin bloquear
define(["jquery"], function ($) {
  return function pintar() {
    $("body").append("<p>hola</p>");
  };
});

Para sobrevivir en ambos mundos apareció UMD, un patrón envolvente que detectaba el entorno y se adaptaba a CommonJS o a AMD. Tres sistemas resolvieron el mismo problema con supuestos distintos, y esos supuestos explican por qué convivieron tanto tiempo:

• CommonJS — síncrono y dinámico: require se resuelve al ejecutar. Ideal en disco, inviable por red sin bloquear.
• AMD — asíncrono y dinámico: declara las dependencias por adelantado para cargarlas sin congelar el navegador.
• ESM — asíncrono y estático: las importaciones se conocen antes de ejecutar, y esa estaticidad es la que después habilita el tree shaking.

El desenlace llegó en 2015, cuando ECMAScript estandarizó ESM con import y export. Por fin un único sistema, estático y analizable, válido tanto para Node como para el navegador. Tardó años en tener soporte completo en ambos, pero unificó una década de fragmentación.

// ESM (estandar, 2015): estatico, import y export
import { readFileSync } from "node:fs";
export function leer(ruta) {
  return readFileSync(ruta, "utf8");
}

De las task runners a los bundlers

Con los módulos resueltos en teoría, faltaba una herramienta que preparase el código para producción. La primera generación fueron task runners. Grunt (2012) orquestaba tareas —concatenar, minificar, comprobar estilo— a partir de un gran objeto de configuración: mucha ceremonia declarativa. Gulp (2013) le respondió con código sobre configuración y con flujos encadenados mediante pipe, más rápidos y legibles.

// Gulp: codigo sobre configuracion, transformaciones encadenadas con pipe
gulp.task("scripts", () =>
  gulp.src("src/*.js").pipe(minificar()).pipe(gulp.dest("dist"))
);

Pero ambos seguían siendo capataces que ejecutaban transformaciones sobre archivos, sin comprender de verdad las dependencias entre ellos. El giro conceptual lo trajo Browserify (2011): en lugar de orquestar tareas, seguía el grafo de require desde un punto de entrada y producía un único archivo que el navegador podía cargar. Trajo CommonJS al navegador empaquetándolo. Esa idea —modelar la aplicación como un grafo de dependencias— la llevó a su máxima expresión webpack (2014).

La revolución de la velocidad y el dev server

Hacia 2019 el modelo de webpack empezó a crujir. A medida que las aplicaciones crecían, empaquetarlo todo antes de servir se volvía caro. El problema ya no era la corrección, sino la velocidad y la experiencia de desarrollo. El diagnóstico de aquel momento se resume en tres síntomas:

• El arranque en frío tardaba decenas de segundos, porque había que empaquetar todo antes de mostrar nada.
• El HMR se degradaba a medida que el grafo crecía, justo cuando el proyecto más lo necesitaba.
• Cambiar una sola línea obligaba a reconstruir artefactos enormes.

Aparecieron dos ideas complementarias. Snowpack propuso no empaquetar en desarrollo: servir ESM nativo y transformar cada archivo por separado, delegando en el propio cargador de módulos del navegador. Y esbuild (2020), escrito en Go, hizo que transformar y empaquetar fueran entre diez y cien veces más rápidos que las herramientas escritas en JavaScript. La síntesis de ambas fue Vite (2021).

flowchart TD
A[2009 CommonJS y Node] --> B[2011 AMD y RequireJS]
B --> C[2012 Grunt y Browserify]
C --> D[2013 Gulp]
D --> E[2014 webpack]
E --> F[2015 ESM estandar]
F --> G[2015 Rollup y tree shaking]
G --> H[2020 esbuild y Snowpack]
H --> I[2021 Vite]
I --> J[2026 Rolldown y Oxc]
style A fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b
style I fill:#a6e3a1,color:#11111b
style J fill:#cba6f7,color:#11111b