Webpack vs Browserify: escogiendo un compilador frontend

Es indiscutible que utilizar una herramienta para empaquetar nuestro código cliente tiene beneficios tanto para el proceso de desarrollo como para el despliegue del proyecto una vez esté en producción. Estos últimos años han ido surgiendo diferentes herramientas, cada vez con mayores funcionalidades y aumentando la flexibilidad del flujo de trabajo. La primera gran herramienta de este tipo fue Grunt, que nos permitía crear tareas para compilación de recursos cliente, como hojas de estilo SASS. Grunt fue reemplazado por Gulp en términos de adopción masiva a principios de 2014, ya que empezó a disponer de un ecosistema más amplio y grandes frameworks, como Laravel con su componente Elixir, lo adoptaron en su codebase. Más tarde surgieron dos herramientas que gozaron de una adopción aún mayor: primero fue Browserify y más tarde Webpack.

Los mejores amigos de Node

Webpack y Browserify tienen una estrecha relación con npm, el gestor de paquetes de NodeJS. Su principal función es posibilitar a los desarrolladores incorporar paquetes de este ecosistema en el código cliente de una aplicación web, mediante el sistema de inclusión de paquetes RequireJS propio de Node. Como es propio de los compiladores de assets, siguiendo la configuración que creemos nos generará un bundle, un archivo JavaScript que contiene todo lo necesario para cargar la página en cuestión. La fundamental diferencia entre Browserify y Webpack en esta cuestión es que Browserify depende de Gulp o Grunt pararealizar la mayoría de estas tareas y Webpack provee toda esta funcionalidad a través de loaders.

Otra fundamental diferencia entre las dos herramientas es que mientras que Browserify se configura mediante un script, Webpack necesita de un archivo de configuración para ejecutarse. Si bien esto puede parecer un punto en contra de Webpack por pérdida de flexibilidad, la realidad es que la sintaxis de configuración de Webpack ofrece la suficiente libertad para crear configuraciones de proyecto muy complejas y a medida.

Hot reloading: ahorrando tiempo de desarrollo

Sin embargo, la principal diferencia entre los competidores, y la que hace que muchos desarrolladores estén apostando por Webpack, es el llamado Hot Reloading que Webpack implementa a través de un loader. Esta funcionalidad consiste en la recarga automática del navegador cuando se detectan cambios en los archivos JavaScript de un proyecto. Este loaders tiene algunas ventajas sobre otros recargadores automáticos como LiveReload; la principal es la posibilidad de guardar el estado de la aplicación entre recargas, muy útil cuando contruimos aplicaciones con mucho código JavaScript en la parte del cliente.

En Sitelabs nos gusta especialmente una característica diferencial de Webpack que consiste en incluir recursos que no son código JavaScript, como hojas de estilo CSS e imágenes desde ficheros JavaScript, mediante el sistema RequireJS. Además, Webpack es lo suficientemente ‘inteligente’ para insertar una hoja de estilos en línea si considera que es lo suficientemente pequeña, y convertir imágenes a codificación base64 en las mismas condiciones. Esto hará que el tiempo entre reacrgas sea aún más reducido y por lo tanto nuestra productividad sea aumentada.

Bundle splitting

Además, Webpack nos permite de serie dividir nuestro código y cargarlo sólo cuando el usuario lo necesite. Este es una de las funcionalidades base que ofrece Webpack, aunque este comportamiento también se puede conseguir usando Browserify a través de paquetes adicionales. Esta característica, llamada splitting, ha demostrado suponer grandes mejoras en los tiempos de carga y procesado de código cuando se implementa de una forma correcta, si lo comparamos con hacer una primera carga más larga y cargarlo después desde la caché.

Browserify, en cambio, tiene una funcionalidad algo más reducida si lo comparamos con Webpack, pero es una baza a nuestro favor si no necesitamos estos extras que nos ofrece Webpack. Si nuestro proyecto no será de gran magnitud o su estructura es relativamente simple, no necesitaremos muchas funcionalidades de las que nos ofrece Webpack.

Lo cierto es que ambas herramientas tienen un conjunto de funcionalidades muy similares, y normalmente la elección de una u otra normalmente se reduce a preferencia personal o necesidad de una funcionalidad muy específica. Constantemente salen a la luz nuevos loaders y módulos implementando funcionalidades que hace años no imaginábamos, y a la vez nuevas herramientas, como SystemJS, surgen para desplazar herramientas ya establecidas, como Webpack ha hecho con sus predecesores. En el caso de herramientas de compilación frontend parece que Webpack ha llegado para quedarse.