Herramientas de JavaScript: La Evolución y Futuro de las Herramientas de JS y Construcción Front-end

Entonces, ¿por qué se construye la web? Las razones esenciales por las que construimos nuestro código frontend hoy en día. Estas razones incluyen la gestión de dependencias, necesitamos poder gestionar todas las dependencias que nuestro código necesita sin tener que preocuparnos de que alguna de ellas se rompa. También necesitamos la transpilación, por lo que necesitamos poder utilizar estas sintaxis data sin problemas de compatibilidad en nuestro navegador. El empaquetado, necesitamos poder agrupar todo nuestro código en un archivo central. La minificación, necesitamos poder reducir el tamaño de nuestro código y tener una entrega más rápida al lado del cliente. Además, una parte muy importante es la gestión de módulos sin utilizar el navegador. Por lo tanto, hay ciertos navegadores que no tienen gestión de módulos, por lo que necesitamos poder gestionar muchos módulos sin tener que preocuparnos por nada.

Entonces, la historia de la construcción web. De 2005 a 2010 se vio la era de los primeros empaquetadores. Dojo fue lanzado en 2005 con su propia herramienta de construcción llamada Dojo Builder que ofrece minificación, eliminación de código muerto, múltiples perfiles de construcción, gestión de módulos y se puede incluso utilizar Node.js para una construcción más rápida. Google Closure Tools también fue lanzado en noviembre de 2009 por Google y tenía un compilador, por lo que esta es básicamente su propia herramienta de construcción que ayuda a eliminar código, código muerto, minimizar código, analizar código y optimizar código. Entonces, los problemas de los primeros empaquetadores y empaquetadores, por qué no eran perfectos. Dojo Builder era pesado. Dependía mucho de Java y tenía una documentación muy pobre. Los problemas del Compilador de Google Closure eran, era propietario, obviamente fue hecho por Google y era una especie de proyecto interno antes de ser lanzado al público. Requería Java 2, el tiempo de compilación era muy lento y tenía una mala experiencia de desarrollo. De 2010 a 2012 se vio la aparición de Gulp y Grunt, fueron los primeros en intentar estandarizar la construcción de canalizaciones utilizables sobre plugins. También dieron a los desarrolladores la libertad de escribir sus propios scripts de construcción y los plugins estaban disponibles para tareas básicas para los desarrolladores. En 2012 se vio la aparición de Babel. Babel permitió a los desarrolladores utilizar la última sintaxis de ASX sin preocuparse por la compatibilidad del navegador. Convierte la sintaxis de ASX en CommonJS y permite a los desarrolladores crear plugins personalizados para sus necesidades. De 2012 a 2014 se vio la aparición de Browserify. Esto fue un cambio de juego principalmente debido a que tenía el poder de npm como un registro de paquetes. Permitía a los desarrolladores utilizar ciertos plugins. Tenía la misma sintaxis que NodeJS y también tenía la sintaxis de módulo ASX, por lo que los desarrolladores estaban bastante contentos, pero tenía sus propias desventajas.

Desde 2015 hasta ahora, hemos presenciado el surgimiento de Webpack, cómo ha crecido de la versión 1 a la versión actual, la versión 5. Muchas grandes empresas están utilizando actualmente Webpack en producción. Es más rápido que Browserify. Tiene un servidor de desarrollo muy bueno llamado Webpack Server. Tiene características como reemplazo de módulos en caliente, división de código, recarga en vivo, etc. También tiene el poder de los scripts de npm, por lo que los desarrolladores pueden escribir sus propios scripts de npm sin preocuparse por nada. Tenía complementos para diversos usos y también tenía preajustes para ampliar las características de Webpack. También ofrecía una mejor experiencia para el desarrollador en comparación con otras herramientas de construcción. Realmente era bueno para los desarrolladores.

Veamos cómo se ve la característica. Así que la característica. Tenemos Rollup. Rollup es un empaquetador de módulos para JavaScript. Fue lanzado hace, digamos, cinco años. Es más fácil de aprender, obviamente, y es una construcción muy rápida. Ofrece características como la división de código. Es realmente, realmente fácil de configurar en comparación con Webpack y es la herramienta de construcción perfecta para construir bibliotecas de JavaScript porque toma pequeñas piezas de código y las convierte en un archivo muy complejo.

Entonces, Parcel. El punto de venta de Parcel cuando se lanzó hace unos dos años fue que no necesitabas ninguna configuración, por lo que el dolor de los desarrolladores al configurar Rollup en Webpack no ocurrió en Parcel. Tenía un tiempo de empaquetado más rápido. Utiliza múltiples procesamientos. Los complementos no son necesarios. Esto se debe a que la configuración de las etiquetas básicas que requieren que los desarrolladores usen complementos ya estaba integrada en Parcel, por lo que la necesidad de complementos no era realmente tan grande. Tiene una experiencia de desarrollo increíble. Tiene una documentación muy buena para los desarrolladores y también una comunidad muy agradable.

Entonces, Snowpack fue lanzado recientemente. El punto de venta es que no necesita empaquetado durante el desarrollo, por lo que omite ese proceso de empaquetado en el desarrollo. Esto se debe al poder de las importaciones de módulos ES. Te brinda la capacidad de omitir el empaquetado durante el desarrollo, aunque necesitas... También proporcionó un complemento donde puedes usar Parcel o Webpack para crear tus propias compilaciones de producción. Actualmente no tiene su propia compilación de producción personalizada. Proporciona reconstrucciones instantáneas en venta, por lo que debido a que no hay nada que volver a empaquetar, tus cambios se reflejan casi de inmediato. Obviamente, también es una construcción más rápida. Tiene soporte incorporado para TypeScript, JavaScript, JSX y módulos CSS, por lo que no necesitas instalar complementos para estas extensiones de lenguaje en particular.

Entonces, ESBuild es básicamente un experimento. Todavía está en fase experimental. El objetivo principal del proyecto es mostrar lo rápido que pueden ser las herramientas de construcción de JavaScript. Es más rápido que Webpack, Rollup y también Parcel. Está escrito en Go, lo que lo hace realmente rápido porque Go se compila a código nativo.

Hasta ahora, parece ser un proyecto muy prometedor. Así que, Importación en el Navegador. Básicamente, la Importación en el Navegador hace uso de tus módulos en tu navegador y tu script en el navegador, dividiendo tu código en piezas más pequeñas y entregándolas como módulos a tu JavaScript en la web, al navegador en sí.

El soporte del navegador no ha sido realmente bueno, pero a medida que la web avanza, el soporte del navegador para la importación de módulos ES también aumenta. Tiene una gran ventaja, como el almacenamiento en caché, por lo que el navegador no... una vez que los módulos se han cargado una vez, el navegador no necesita volver a cargar todo a menos que haya un cambio en uno de los módulos. También puedes usar async o defer en la etiqueta de script para especificar tus módulos como async o defer, lo cual es una característica muy interesante para los módulos ES.

Y por último, tenemos enfoques sin empaquetado, como el Sistema de Importación en Tiempo de Ejecución. Básicamente, los enfoques sin empaquetado utilizan módulos ES, por lo que no necesitarías webpack, Parcel u otras herramientas de construcción para esto. Básicamente, estarías empaquetando directamente en la web, por lo que no hay empaquetado. Para todas las producciones... Si necesitas una producción... Definitivamente no necesitarías una compilación de producción, y un ejemplo es Snowpack. Snowpack está tratando de utilizar el enfoque sin empaquetado con módulos ES. Aún no se utiliza mucho, todavía es experimental, y si logramos lograr el enfoque sin empaquetado, tendremos construcciones ultrarrápidas y también tiempos de implementación rápidos.

En conclusión, el ecosistema de JavaScript es dinámico. Cambia y solo las mejores herramientas pueden sobrevivir técnicamente. Es básicamente una competencia. En el futuro, veremos herramientas sin configuración, sin configuración en absoluto, una mayor personalización para dar a los desarrolladores más flexibilidad para hacer lo que quieran hacer, más características de extensibilidad y velocidades más rápidas. Velocidades de construcción ultrarrápidas. La elección de las herramientas de construcción que los desarrolladores utilizarán para el front-end de una aplicación es básicamente un código personal basado en los requisitos del proyecto. Es como elegir lo que funciona mejor para ti, básicamente, para ese proyecto en particular. Y la mayoría de las veces, la selección de las herramientas de construcción implica hacer concesiones.

Por último, se dispone de referencias y recursos útiles. Si necesitas más conocimientos sobre lo que he hablado hoy, puedes consultar estos enlaces. Muchas gracias por venir a mi charla, lo aprecio. Espero que disfrutes del resto de la conferencia. Gracias.