El coste del build y cuándo no lo necesitas

El build resuelve problemas reales, pero no es gratis. Cada capa que añades —un bundler, sus plugins, sus dependencias— tiene un precio en configuración, en tiempo y en distancia entre lo que escribes y lo que depuras. En 2026, con ESM nativo universal, import maps y CDN que sirven ESM listo para usar, existe un mundo buildless que para ciertos proyectos es la mejor decisión. Saber cuándo el build sobra es tan importante como saber usarlo.

El impuesto que pagas por compilar

El coste obvio es el tiempo de build, pero es el menos importante. Los caros son los otros, y conviene enumerarlos porque rara vez se contabilizan:

• Configuración: archivos que aprender, plugins que encajar y que a veces se rompen entre versiones mayores.
• Dependencias: un node_modules de cientos de megabytes donde cada paquete es superficie de ataque.
• Cadena de suministro: una dependencia de build puede ejecutar código arbitrario en tu máquina o en tu CI; es hoy uno de los vectores de seguridad más activos.
• Indirección: entre lo que escribes y lo que se ejecuta hay una transformación, y cuando algo falla depuras a través de ella.
• Deriva de versiones: el clásico “en mi máquina funciona” nace muchas veces de dos versiones distintas del toolchain.

De todos, el más insidioso es la indirección. Los source maps ayudan, pero no siempre son perfectos: hay bugs que solo aparecen en el artefacto compilado y no en tu fuente, y diagnosticarlos exige entender la propia herramienta.

Cada capa que interpones entre tu código y el navegador es una capa más donde el problema puede esconderse. Y no es solo técnica: es también organizativa. Un build sofisticado sube la barrera de entrada de quien se incorpora, ata el proyecto a un ecosistema del que migrar cuesta y exige mantenimiento continuo a medida que las herramientas evolucionan.

El mundo buildless

La razón por la que hoy se puede prescindir del build es simple: el problema original se ha erosionado. Los navegadores evergreen de 2026 soportan ESM de forma universal, así que el JavaScript moderno se ejecuta sin transformar.

Solo queda el cabo suelto de los bare specifiers —el navegador no sabe qué es lodash-es—, y para eso existe una solución estándar del propio navegador: los import maps. Un import map es un bloque que le enseña al navegador a traducir un nombre de paquete a una URL real.

Combinado con un CDN de ESM —esm.sh, jsDelivr, unpkg— que sirve cualquier paquete de npm ya convertido a módulos, la resolución de dependencias ocurre sin bundler ni node_modules:

<!-- Sin build: el navegador resuelve lodash-es via import map y CDN -->
<script type="importmap">
{
  "imports": {
    "lodash-es": "https://esm.sh/lodash-es@4.17.21"
  }
}
</script>
<script type="module">
  import { debounce } from "lodash-es";
  window.addEventListener("resize", debounce(() => console.log("fin"), 200));
</script>

Sobre esta base florece todo un estilo de desarrollo sin compilación. Las piezas nativas de la plataforma —los Web Components— permiten crear componentes reutilizables sin ningún framework ni transpilación:

// Un componente reutilizable, sin build ni framework: solo la plataforma
class SaludoBox extends HTMLElement {
  connectedCallback() {
    this.innerHTML = "<p>Hola desde un Web Component</p>";
  }
}
customElements.define("saludo-box", SaludoBox);

A ello se suman librerías que viven en una etiqueta <script> —htmx para intercambiar HTML, Alpine o Lit para interactividad ligera— y JavaScript vanilla que se ejecuta tal cual se escribe. Para muchos proyectos, esto no es un apaño: es la opción más limpia.

Dónde el buildless se rompe

El buildless tiene un techo, y conviene verlo con honestidad. Cada cosa que el bundler hacía por ti desaparece, y hay que decidir si la echas de menos:

• Sin empaquetado: cada módulo es una petición, y un grafo profundo se convierte en una cascada de descargas encadenadas que ni HTTP/2 salva del todo.
• Sin tree shaking ni minificación: envías más bytes de los necesarios, sin poda de código muerto.
• Sin TypeScript ni JSX: salvo que aceptes transformarlos en el navegador —lento— o cedas y montes un build mínimo.
• Versionado frágil: fijar versiones e integridad de decenas de dependencias desde URLs sueltas es más frágil que un lockfile.

flowchart TD
A[Necesito una web] --> B{Usa TypeScript o JSX}
B -->|si| C[Necesitas build]
B -->|no| D{Cuantas dependencias}
D -->|muchas o profundas| C
D -->|pocas o ninguna| E{Es publica y de alto trafico}
E -->|si| C
E -->|no| F[Buildless es suficiente]
style C fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

La conclusión no es que un extremo gane. El build y el buildless son los dos polos de un continuo, y el error caro es tratar la pregunta como binaria o dejar que la costumbre decida por ti. Montar webpack para una landing de tres páginas es tan desproporcionado como servir sin empaquetar una aplicación con cuatrocientas dependencias.

Piensa el build como un dial, no como un interruptor. Entre no compilar nada y un monorepo con caching distribuido hay grados, y cada proyecto vive mejor en uno de ellos: