Para que es Webpack?

Respuesta corta: Porque si!
Respuesta larga: Continua leyendo 😉

Porque debemos usar Webpack

Seamos francos al comenzar el desarrollo de aplicaciones SPA basadas en Javascript puede resultar tan sencillo como disfrutar un helado en verano, dulce y divertido, pero al poco tiempo puede tornarse en un montón capas enredadas que se comunican entre sí, capas y capas de soluciones que resuelven problemas y esto en algún punto puede ser realmente doloroso. Por fortuna y gracias al tornado de nuevas herramientas hace que cada vez el camino del desarrollo Frontend sea más confortable y delicioso.
Una de estas herramientas es Webpack que llega al rescate y nos ayuda en la labor de construir increíbles y hermosas aplicaciones SPA-PWA. YEP ! 😎.
Bien, a lo largo de este articulo vamos a definir lo que hace Webpack por nosotros, vamos a revisar qué es lo que Webpack hacer para nosotros, pero antes vamos a ver un poco de contexto histórico.

Un poco de Historia

Hace millones y millones de nanosegundos cuando la web se comenzaba a formar, nació un lenguaje de programación de scripting al que muchos catalogaron de juguete, había nacido Javascript que nos ayudaba a dar interactividad a esas páginas web estáticas, que básicamente eran documentos con hyperlinks que se conectaban unos con otros, en aquellos inicios este peculiar lenguaje se usaba para recabar datos de formularios, abrir ventanas emergentes, incluso algunos programadores osados lo utilizaban para hacer algunos efectos lindos y brillosos en las páginas, como caer nieve (aham aham). 😱 Bien en esos tiempos rudimentarios y primitivos el usar Javascript era tan simple como poner una etiqueta de script con la locación del código:

<script src=”http://my.javascript.code"></script>

Todo funcionaba de maravilla, nuestro simpático efecto de nieve funcionaba, podíamos recopilar datos de formularios y todo era perfecto, ¿Bien que paso despues? Bueno llego un tiempo oscuro para Javascript ya que la falta de estandarización y la guerra de los navegadores, el tener que escribir varias versiones de Javascript para que fuera consistente en todos los navegadores (IE aham!) La llegada de Macromedia~Adobe Flash que por un tiempo fue el standard, bueno esto ocasionó que el camino de Javascript detuviera su evolución por varios años.

Todo funcionaba de maravilla, nuestro simpático efecto de nieve funcionaba, podíamos recopilar datos de formularios y todo era perfecto, ¿Bien que paso despues? Bueno llego un tiempo oscuro para Javascript ya que la falta de estandarización y la guerra de los navegadores, el tener que escribir varias versiones de Javascript para que fuera consistente en todos los navegadores (IE aham!) La llegada de Macromedia~Adobe Flash que por un tiempo fue el standard, bueno esto ocasionó que el camino de Javascript detuviera su evolución por varios años.

Luego llegó la época de luz de Javascript cuando liberaron los estándares abiertos HTML5, CSS3 todos comenzaron a ver a ese patito feo de los lenguajes de programación “Javascript”, el estándar logró seguir evolucionando, èl poder usar el objeto XMLHttpRequest del navegador para hacer solicitudes asíncronas al servidor, con esto ya teníamos la posibilidad de recargar partes específicas de la página sin tener que cargar la página completa, lo que desencadenó en tener una mejor experiencia de usuario ¡Yija! 😁, asi nacieron y se extendieron las Single Web Applications SPA, que nos daban una experiencia similar a las aplicaciones de escritorio convencionales, aquí es donde todo explota ✨ y muchas grandes empresas comienzan a tener inversiones en estándares abiertos, comienzan a salir miles de librerías. Ok… ok.. Pero ¿Que no estábamos hablando de Webpack? Estas todo emocionado pero ¿Hablábamos de Webpack o No? — ¡ Bueno si ! Ya casi termino. — Cuando ocurre esto, se dejan de tener archivos javascript de 100 líneas y pasan a tener miles y miles de ellas y por desgracias a mayor lineas de codigo, aumenta la complejidad y esta complejidad no crece lineal, sino exponencialmente y dejamos de tener una llamada con una etiqueta script a tener varias:

<script src=”http://jquery...”></script>
<script src=”http://library1..."></script>
<script src=”http://library2..."></script>
<script src=”http://library3..."></script>
<script src=”http://library4..."></script>

El problema con esto era que por cada etiqueta tenía que hacer una llamada HTTP al servidor, lo que ocasionaba lentitud al cargar la aplicación / website, entonces el siguiente paso fue que surgieron herramientas online de concatenación, compresión / minificación de Javascript que tomaba el código de las librerías y nuestro código fuente y lo compactan en un solo archivo, quedando de la siguiente forma:

<script src=”http:mysourcecode”></script>

¿Suena genial? Pero ahora sí ¿Podemos hablar de Webpack? — ¡Todavía no! Ya casi— Es verdad que ahora solo había 1 solicitud HTTP a nuestro código fuente y la página cargaba mucho más rápido pero ahora surge un nuevo problema, es que cuando había grandes equipos de trabajo que constantemente actualizan las websites / aplicaciones, existían muchas tareas repetitivas como correr Test unitarios, comprimir imagenes, organizar de forma estructurada esas imágenes, las hojas de estilos CSS, comprimir los códigos fuente de librerías y luego concatenarlos, despues subirlos algun servidor o CDN para produccion — ¡Sabes que!… mmm. ¡Esto suena doloroso y tedioso! — ¡Mejor me voy a programar en Backend y me quito de problemas! — Basta ya! No seas quisquilloso! Pronto llegaremos a Webpack y comprenderás toda su magia y dejaras que ella sane todas tus dudas y sigas con tus intenciones de ser un gran desarrollador Frontend Ninja! — Bueno en este punto ya había nacido Node.js que es Javascript pero fuera del navegador! Ohh si, ahora ya no se tenían las restricciones que nos impone el navegador para acceder al sistema de archivos, con esto comenzaron a surgir grandes herramientas, como automatizadores de tareas, como Grunt… — ¡Ok y ese tal Grunt ¿Que puede hacer por mi? ¡Bien! Te acuerdas cuando te dije que cuando había despliegues y actualizaciones constantes existían muchas tareas repetitivas que eran un lío en equipos de trabajo? Aham… ¡Si, fue hace unas líneas arriba! — Bien pues Grunt nos permite automatizar todas esas tareas, comprimir imagenes, correr Test, concatenar estilos, comprimir y concatenar código javascript con un solo comando. ¡Wooou, eso suena bien, cuentame más!

Bien la comunidad dio un gran impulso a Grunt creando grandes plugins, sin embargo tenía un problema y es que la arquitectura de Grunt era un poco anticuada para grandes proyectos ya que utilizaba la escritura de archivos temporales en el disco, funcionaba algo asi, primero leía tus archivos, después los iba procesando, generaba algunos archivos temporales y después se trabajaban esos archivos para generar los archivos finales para producción, lo que ocasiona que en proyectos grandes se comportara lento, así que como en el desarrollo Javascript nadie es el rey por siempre, nació Gulp, la utilidad era prácticamente la misma que Grunt con la gran ventaja que no utilizaba escritura de temporales en el disco, en su lugar utilizaba streams de datos, cual corro de datos que al mismo tiempo que los iba leyendo los procesaba y del otro lado del tubo se iban creando los archivos finales 💪, por lo que el rendimiento en grandes proyectos era óptimo… — ¡Esto pinta bien y despues nacio Webpack! o ¿como? — Si, ya casi, sigue leyendo y encontrarás las respuestas.

Módulos y gestores de Dependencias

Bien hasta este punto tenemos los automatizadores de tareas y esta ¡Chevere Cool y Guay! Pero todavía tenemos 2 grandes problemas, de qué forma podemos controlar nuestras dependencias y como organizar y modularizar nuestro codigo con un sistema de módulos.

Sistemas de dependencias

El auge y crecimiento de Javascript es tan fuerte y las librerías evolucionan con tanta rapidez que surge la necesidad de buscar la forma de poder saber qué dependencias (librerías, utilidades etc.) Requerimos para nuestro proyecto y de qué versión específicamente. Un buen día, vio la luz Bower, creado por el equipo de Twitter, el cual utilizaba Node.js como plataforma y con él podíamos hacer instalación de dependencias con un simple comando Bower install tu-dependencia También se nos generaba un manifiesto con las dependencias y su versión concreta`en un archivo que crea llamado bower.json, entonces ahora para poder distribuir nuestro proyecto, solo enviamos el código fuente (El código que escribimos nosotros) y el manifiesto bower.json y con el comando bower install se instalaban todas las dependencias necesarias declaradas en bower.json — ¡Yeah pajarito de Bower, tu lo haces bien!

Sistema de Módulos

Uno de los grandes problemas de Javascript es que los navegadores no soportan un sistema nativo de módulos por lo que en proyectos grandes complica la forma de definir una arquitectura y poder modularizar nuestro código fuente, la comunidad Javascript al ver este problema creo varios sistemas de módulos, pero los 2 mas importantes fueron AMD (Asynchronous Module Definition) con la librería Require.js y otro con Common JS que es el sistema de módulos nativo de Node.js — “Recuerdas, Javascript fuera del navegador, donde se creó Grunt, Gulp y Bower” — ¡Así, Genial! Puedes proseguir.

Bien, un buen dia a un brujo ermitaño de las aldeas zugarramurdi lanzó un hechizo y a un gran hombre se le ocurrió usar NPM que es el administrador de dependencias de Node.js y poder usar el sistema de módulos nativo de Node.js El ya nombrado Common JS, después empaquetar esos módulos y dependencias para que el código resultante fuera compatible con el navegador, así nació Browserify — ¡Oh yep! ¡Magia pura y dura amigo mio!
Ventajas:
- Usar NPM como gestor de dependencias en lugar de Bower.
- Usar CommonJS como sistema de módulos.

¡Esto esta Genial! Pero como que me acuerdo que este articulo era de Webpack? ¡Si, bueno después de algún tiempo nació Webpack! Que al igual que Browserify podía empaquetar módulos y utilizar NPM como gestor de dependencias, con la gran ventaja de que era compatible con CommonJS y con AMD los 2 sistemas de módulos más comunes para Javascript, otra gran ventaja de Webpack es que hasta cierto punto podemos utilizarlo como un automatizador de tareas como Grund o Gulp, para minificación de archivos, comprimir imágenes, y poder utilizar las nuevas especificaciones de Javascript EcmaScript 2016–2017 con la traducción de transpiradores como Babel o Typescript a Javascript que entienda cualquier navegador, poder transpirar compiladores de hojas de estilos CSS como SASS o Stylus y poder hacer code Splitting(Separar nuestro código en trozos y enviarlos a medida de que el usuario los necesite, provocando una carga inicial mucho más rápida y una mejor experiencia de usuario UX). La filosofía de Webpack es tratar a todo como un módulo, por lo que cualquier archivo como imágenes, fuentes, archivos.json, etc. serán tratados como módulos y para usarlos se deben incluir sus respectivos cargadores(Loaders) Webpack Tiene una gran serie de herramientas fuera de la caja y su configuración es muy simple, Webpack nos soluciona todos los problemas de los que hablábamos anteriormente y va mucho más allá, esta es una de las herramientas más poderosas que existen en el arsenal Frontend al dia de hoy, sin importar tu stack de desarrollo, sea Angular, React, Vue, Ember o Vanilla JS, sin duda debes aprenderlo.

Conclusión

Ya hace tanto tiempo que se han quedado atrás, aquellas páginas simples donde Javascript solo era para manejar interactividad primitiva como enviar algunas alertas, enviar o montar un par de efectos en la página, ahora tenemos páginas ricas que pueden hacer prácticamente lo mismo que hacen nuestras aplicaciones nativas de escritorio o móviles y todo esto está a la distancia de una URL o un click, pero tanta belleza tiene un costo, el poder conocer y utilizar estas herramientas nos despejara el camino para cimentar nuestros desarrollos 😎.

Si quieres saber más puedes ver un curso en video que estoy haciendo a medida de que el tiempo me lo permita, el cual puedes encontrar aquí.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.