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

Rate this content
Bookmark

En esta charla, repasaré la evolución de las herramientas de JavaScript y las herramientas de construcción front-end, el propio JavaScript y su futuro.


También hablaré sobre Babel y otras herramientas de construcción, lo que podrían ser en el futuro. Además, hablaré sobre JavaScript en sí como lenguaje, su presente y su futuro.

11 min
18 Jun, 2021

Video Summary and Transcription

La charla de hoy aborda la evolución y futuro de las herramientas de JavaScript, incluyendo la gestión de dependencias, la transpilación, el empaquetado, la minificación y la gestión de módulos. Webpack ha ganado popularidad y ofrece características como la sustitución de módulos en caliente y la división de código. También se discuten otras herramientas de construcción como Rollup, Parcel, Snowpack y ESBuild. La charla explora enfoques de importación en el navegador y sin empaquetado, y enfatiza la naturaleza dinámica del ecosistema de JavaScript con herramientas en constante evolución y compensaciones específicas del proyecto.

Available in English

1. Introducción a las herramientas de JavaScript

Short description:

Hola a todos. Hoy voy a hablar sobre las herramientas de JavaScript, la evolución y el futuro de JavaScript y las herramientas de construcción frontend. Las razones esenciales por las que construimos nuestro código frontend hoy en día incluyen la gestión de dependencias, la transpilación, el empaquetado, la minificación y la gestión de módulos utilizando el navegador. La historia de la construcción web comenzó con los primeros empaquetadores como Dojo y Google Closure Tools. Sin embargo, estas herramientas tenían sus propios problemas. Luego, surgieron Gulp, Grunt, Babel y Browserify con sus propias soluciones para mejorar el proceso de desarrollo.

Mi nombre es Cedric Alcantara. Soy un Desarrollador Certificado. Hoy voy a hablar sobre las herramientas de JavaScript, la evolución y el futuro de JavaScript y las herramientas de construcción frontend. Soy un Desarrollador Social, soy un Defensor del Desarrollador y también soy un Autor Técnico Invitado en Smashing Magazine.

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.

2. Webpack y sus características

Short description:

Desde 2015 hasta ahora, Webpack ha crecido de la versión 1 a la versión 5 y es utilizado por muchas grandes empresas en producción. Es más rápido que Browserify y ofrece características como reemplazo de módulos en caliente, división de código y recarga en vivo. Webpack también tiene el poder de los scripts de npm, lo que permite a los desarrolladores escribir sus propios scripts sin preocupaciones. Con complementos y preajustes, proporciona una mejor experiencia para el desarrollador.

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.

3. JavaScript Build Tools

Short description:

Veamos cómo se ve la característica. Rollup es un empaquetador de módulos para JavaScript. Es más fácil de aprender, muy rápido y ofrece división de código. Parcel, lanzado hace dos años, no requiere configuración, tiene un tiempo de empaquetado más rápido y una experiencia de desarrollo increíble. Snowpack omite el empaquetado durante el desarrollo, proporciona reconstrucciones instantáneas y tiene soporte incorporado para TypeScript, JavaScript, JSX y módulos CSS. ESBuild es un proyecto experimental que tiene como objetivo mostrar lo rápido que pueden ser las herramientas de construcción de JavaScript, escrito en Go para la compilación de código nativo.

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.

4. Enfoques de Importación en el Navegador y sin Empaquetado

Short description:

La Importación en el Navegador permite dividir el código en módulos más pequeños para su entrega al navegador. El soporte del navegador para los módulos ES está aumentando, ofreciendo ventajas como el almacenamiento en caché y las opciones async/defer. Los enfoques sin empaquetado, como el Sistema de Importación en Tiempo de Ejecución y Snowpack, buscan mejorar los tiempos de construcción e implementación. El ecosistema de JavaScript es dinámico, con herramientas que evolucionan para ofrecer una mayor personalización, extensibilidad y velocidades de construcción más rápidas. Los desarrolladores eligen las herramientas de construcción en función de los requisitos del proyecto, a menudo haciendo concesiones. Se dispone de referencias y recursos para obtener más conocimientos.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).