¿Por qué es necesario compilar el frontend?

HTML admite dos formas de trabajar con JavaScript. La primera es agregar el código directamente en la página y la segunda es cargar el código desde un archivo especificado en la etiqueta <script>.

Scripts en línea

La primera forma es la siguiente.

<script>
  document.getElementById('demo').innerHTML = 'Hello JavaScript!';
</script>

Esto solo funciona en situaciones muy simples. A veces se utiliza para agregar pequeños elementos interactivos, como autocompletar y conmutadores de pestañas.

Código en archivos

El frontend moderno ha avanzado mucho más allá de estas tareas. La cantidad de código JavaScript en muchos proyectos alcanza decenas o cientos de miles de líneas de código. Es físicamente imposible mantener tal cantidad de código dentro de HTML. Por lo tanto, se coloca en archivos separados, que pueden ser muchos. El segundo método se utiliza para su inclusión.

<!--
Cuando el navegador encuentra una etiqueta `<script>` con una ruta `src`,
carga el archivo especificado y lo ejecuta.
De esta manera, el código tiene acceso al contenido de la página.
-->

<!-- Todas las definiciones dentro se vuelven globales y están disponibles para todos los demás scripts -->
<script src="/assets/script1.js"></script>
<script src="/assets/script2.js"></script>

La etiqueta <script> se agregó a HTML hace mucho tiempo, mucho antes de que apareciera la versión moderna del lenguaje con módulos. En aquellos tiempos no existía Node.js, un administrador de paquetes y el concepto de "dependencias". Todo el código se escribía en un solo archivo. Incluso si había varios archivos, no estaban relacionados entre sí. Si intentas usar módulos junto con la etiqueta <script> normal, el navegador mostrará un error.

Uncaught SyntaxError: Cannot use import statement outside a module

En teoría, se puede escribir código sin utilizar un sistema de módulos, pero este enfoque es extremadamente laborioso y se basa en que todas las definiciones en el código son globales (lo que significa que se puede romper fácilmente sobrescribiendo definiciones existentes). Tendrías que especificar manualmente todos los archivos existentes y cargarlos en HTML en un orden estrictamente definido. Hoy esto solo se ve en sitios heredados o en páginas con muy poco JavaScript.

La falta de módulos hace que el desarrollo normal sea imposible. No se pueden manejar las dependencias, no se pueden escribir pruebas, no hay análisis estático de código (no se pueden navegar por las definiciones, no hay sugerencias).

Módulos en el navegador

El problema de la falta de módulos en el navegador es tan importante que en HTML5 se introdujo el soporte para módulos de JavaScript. Simplemente agregue type="module" a la etiqueta <script> y el navegador comenzará a entenderlos y cargarlos. Los módulos son compatibles con casi todos los navegadores modernos.

En HTML.

<script type="module" src="/assets/index.js"></script>

En JavaScript.

// index.js

import app from './app.js';

app();

// app.js

export default () => {
  console.log('Hello from module!');
};

Los módulos en el navegador cambian mucho la forma de trabajar con JavaScript, pero tienen un "pero" importante. El navegador no sabe resolver por sí solo los paquetes instalados en node_modules. Si instalamos, por ejemplo, lodash, el intento de importarlo con su nombre dará como resultado un error. El navegador no sabe nada sobre el sistema de archivos de tu proyecto ni sobre lo que hay allí.

Uncaught TypeError: Failed to resolve module specifier "lodash".
Relative references must start with either "/", "./", or "../".

Este problema se puede resolver en el propio navegador con import maps, un bloque <script type="importmap"> que asocia el nombre del paquete con una dirección. Sin embargo, en proyectos reales sigue siendo más práctico usar un sistema de compilación que gestione las dependencias, la minificación y el código de TypeScript.

Compiladores de frontend

Estos problemas se resuelven con los sistemas de compilación. Además de cargar archivos, resuelven muchas otras tareas igualmente importantes. El desarrollo frontend se basa en una variedad de preprocesadores y postprocesadores. Por ejemplo, Babel toma el código fuente del proyecto y lo transforma en un código que entienden los navegadores y entornos más antiguos, o aplica transformaciones especiales (como la sintaxis de JSX en React). Los navegadores actuales entienden la mayor parte de JavaScript moderno, así que hoy Babel hace falta con menos frecuencia, y en muchos proyectos con TypeScript esta transformación la hacen herramientas integradas como esbuild, SWC o Vite. Solo después de la compilación se entrega el código al cliente.

Para usar Babel desde la línea de comandos se instalan sus paquetes con npm i -D @babel/core @babel/cli, y luego se ejecuta el comando de compilación.

# Especificamos el directorio de origen src
# Y el directorio donde colocar el código compilado
babel src -o dist

Lo mismo ocurre con CSS. Muchos desarrolladores utilizan Sass, que debe ser compilado a CSS puro. Se instala con npm i -D sass y se ejecuta así.

# Especificamos el directorio de origen stylesheets
# Y el directorio donde colocar el CSS compilado
sass --update stylesheets:dist/stylesheets

Además de estas tareas, los compiladores se encargan de lo siguiente.

• Proporcionan un comando único para compilar completamente el frontend, incluidas todas sus partes.
• Vuelven a compilar automáticamente el frontend durante el desarrollo. Lo hacen muy rápido gracias al uso de compilación incremental (compilan solo lo que ha cambiado).
• Garantizan el rendimiento. Minifican y comprimen el código (incluido el código no utilizado). Lo dividen de la manera más conveniente para el almacenamiento en caché.
• Realizan cualquier transformación, por ejemplo, TypeScript => JavaScript. Permiten agregar preprocesadores y postprocesadores, configurar el orden en que se aplican a los archivos seleccionados.

Si realizas estas tareas manualmente, la preparación del código para su ejecución en el navegador llevará más tiempo que el propio desarrollo.

Webpack

Uno de los primeros compiladores de frontend fue Webpack. Sigue muy presente en proyectos existentes, pero para empezar proyectos nuevos hoy se suele usar Vite (o el sistema de compilación integrado del framework, como Turbopack en Next.js). Vite se crea con npm create vite@latest y en su versión actual empaqueta el código con Rolldown. Aun así, conocer Webpack ayuda a entender cómo funcionan todos estos sistemas, porque las ideas son las mismas. El principio general de funcionamiento de Webpack es el siguiente. Se instala Webpack en el proyecto y se describe su configuración. Esta configuración contiene todas las reglas de compilación, es decir, qué archivos tomar, qué manipuladores aplicar a ellos y dónde colocar el resultado. Como resultado, Webpack genera un archivo o conjunto de archivos listos para cargar en el navegador. A partir de ahí, no participa, el uso de estos archivos es responsabilidad del programador.

Webpack se suministra como una biblioteca npm y se instala en el proyecto, generalmente como una dependencia de desarrollo, y para trabajar es conveniente utilizar la utilidad de línea de comandos.

mkdir webpack-demo
cd webpack-demo
npm init -y
npm i -D webpack webpack-cli

Para no escribir la configuración desde cero, Webpack cuenta con un generador de proyectos aparte, create-webpack-app. Con un solo comando crea los archivos y la configuración necesarios.

npx create-webpack-app webpack-demo

El generador hace algunas preguntas sobre las opciones de la aplicación futura. Si se agrega la bandera --force, se genera el proyecto con las respuestas por defecto, y con --template se puede elegir una plantilla (default, react, vue o svelte). Webpack CLI 7 requiere Node.js 20.9 o superior.

Cuando el proyecto esté listo, se puede iniciar el servidor de desarrollo.

npx webpack serve

Este comando compilará la aplicación en modo de desarrollo y la servirá en el navegador.

El archivo de configuración webpack.config.js contendrá los complementos necesarios para trabajar con HTML. ¡Todo está listo para escribir tu primera aplicación frontend utilizando Webpack!

La mejor manera de continuar trabajando con él es leer la documentación oficial.