El futuro de las herramientas de construcción frontend

 

 

 

  • ¡Registro!
  • SmashingConf Friburgo 2024

  • Índice
    1. El pasado
    2. El presente
    3. El futuro
    4. Una nueva plataforma
    5. Un cambio de paradigma
      1. 1. Compatibilidad del navegador para funciones de vanguardia
      2. 2. Procesamiento de importaciones de módulos de nodo
    6. Pensamientos finales
      1. Lecturas adicionales sobre la revista Smashing

    Este artículo explora el concepto de herramientas para el desarrollo frontend en la web. Aprenderá por qué necesitamos herramientas frontend, las diversas etapas de evolución por las que han pasado y los nuevos desarrollos que darán forma a las herramientas de construcción frontend del futuro. Para seguir este artículo, es necesaria una comprensión general del desarrollo frontend moderno en la web.

     

    Las herramientas de construcción frontend son cruciales para el flujo de trabajo del desarrollador frontend moderno por una serie de razones clasificadas en experiencias mejoradas para desarrolladores y usuarios. Desde la perspectiva del desarrollador, las herramientas frontend nos brindan: la capacidad de crear módulos, un servidor de desarrollo para el desarrollo local, reemplazo de módulo en caliente (HMR) para un ciclo de retroalimentación más corto en el modo de desarrollo, la capacidad de apuntar a navegadores heredados con polyfills, procesar un host de tipos de archivos además de JavaScript, la lista continúa.

    Como resultado, los usuarios pueden disfrutar de aplicaciones más capaces y ricas en funciones que mantienen su rendimiento mediante técnicas como división de código, almacenamiento en caché, captación previa y otras técnicas de optimización de recursos, y algunas aplicaciones incluso pueden funcionar sin conexión.

    Las herramientas frontend nos brindan tanto hoy en día que es difícil imaginar que hubo un momento en el que ni siquiera eran necesarias. Un viaje al pasado podría ayudarnos a comprender cómo llegamos hasta aquí.

    El pasado

    Antes de que las aplicaciones frontend se volvieran tan complejas como lo son hoy, todo lo que se usaba JavaScript era agregar interactividad básica a documentos HTML que de otro modo serían simples, similar a la forma en que se usaba Flash de Adobe.

     

    No había aplicaciones complejas con mucho JavaScript, por lo que no se necesitaba ninguna herramienta para mejorar la creación y el envío de JavaScript, pero ese no seguiría siendo el caso.

    A medida que pasó el tiempo y comenzamos a crear experiencias de usuario más involucradas en la web, pasamos de páginas web más estáticas a aplicaciones web altamente dinámicas que brindan datos específicos del usuario. Estas aplicaciones requerían más JavaScript que sus contrapartes tradicionales y los límites de trabajar con JavaScript se hicieron mucho más evidentes.

    Hay dos formas principales de cargar JavaScript en el navegador. Uno es con una etiqueta de secuencia de comandos que hace referencia a un archivo JavaScript y el otro es escribir su JavaScript directamente en el HTML dentro de las etiquetas de secuencia de comandos.

    script src="my-javascript-file.js"/scriptscript var a = 1; var b = 2; var result = a + b;/script

    Esta limitación en la carga de JavaScript se convierte en un cuello de botella cuando hay mucho JavaScript para cargar. Existen limitaciones del navegador para cargar muchos archivos JavaScript simultáneamente y problemas de mantenimiento al tener un archivo JavaScript enorme (como tamaño de archivo, problemas de alcance, colisión de espacios de nombres, etc.).

    Se nos ocurrieron soluciones como expresiones de funciones invocadas inmediatamente (IIFE) para ayudar con la encapsulación y algunos de los problemas de alcance, después de lo cual obtuvimos la capacidad de escribir nuestro JavaScript en muchos archivos diferentes. Luego, necesitábamos una forma de combinar todos estos archivos en un solo archivo para publicarlo en el navegador.

    El presente

    Al poder dividir nuestro JavaScript en diferentes archivos con IIFE, parecía que todo lo que necesitábamos era una forma de concatenar estos archivos y enviar un solo archivo al navegador. Esta necesidad provocó el surgimiento de herramientas como Gulp, Grunt, Brocolli, etc. Sin embargo, pronto nos dimos cuenta de que nuestro pensamiento podría haber sido demasiado simplista.

    A medida que nuestras aplicaciones se volvieron aún más complejas, cuestiones como la falta de eliminación de código inactivo, reconstrucciones completas para pequeños cambios y otros problemas de rendimiento nos hicieron darnos cuenta de que necesitábamos algo más que una simple concatenación. Eso dio lugar a paquetes más modernos como Webpack, Parcel y otros.

    Dado que el ritmo de avance en el espacio frontend no disminuye, hemos comenzado a observar brechas y problemas con las herramientas de compilación modernas.

    Algunas de las principales limitaciones incluyen:

    • Instalación y configuración complejas de algunos de estos paquetes existentes;
    • Aumento de los tiempos de compilación a medida que las aplicaciones crecen;
    • Rendimiento subóptimo en modo de desarrollo.

    El ritmo al que cambian las cosas en el ecosistema de JavaScript suele ser agotador, pero lo bueno es que la comunidad identifica rápidamente los problemas y se pone a trabajar en posibles soluciones. Con la mira puesta en mejorar el rendimiento de las herramientas frontend, se está desarrollando una nueva generación de herramientas de construcción.

    El futuro

    Las limitaciones de las principales herramientas de compilación de la actualidad han llevado a varios intentos de reimaginar lo que debería ser y hacer una herramienta de compilación frontend, y hoy en día existen bastantes herramientas de compilación nuevas.

     

    Una inspección más cercana revelará que estas nuevas herramientas parecen estar adoptando dos enfoques principales para resolver el problema (no necesariamente mutuamente excluyentes): un cambio de paradigma y un cambio de plataforma, ambos impulsados ​​por nuevos avances en el ecosistema de desarrollo web.

    Una nueva plataforma

    Las herramientas de creación de frontend se han creado tradicionalmente con JavaScript y, más recientemente, con Typecript. Esto tenía sentido, ya que JavaScript es el lenguaje de la web, y la creación de herramientas de creación para la web en el mismo idioma facilita que más personas contribuyan al esfuerzo y creen una comunidad en torno a estas herramientas. Aún así, existen problemas inherentes a este enfoque.

    Como lenguaje de alto nivel, JavaScript no puede alcanzar niveles nativos de rendimiento. Esto significa que las herramientas creadas sobre esta plataforma tienen un límite en su rendimiento. Entonces, para superar esta limitación, se están creando herramientas de compilación más nuevas en lenguajes de nivel inferior e inherentemente de mayor rendimiento, como Rust.

    Lenguajes como Rust y Go se han convertido en opciones populares para crear la próxima generación de herramientas de compilación con un fuerte énfasis en el rendimiento. Rust, en particular, es popular no solo por su rendimiento sino también por su impresionante experiencia de desarrollador: votado como el lenguaje de programación "más querido" durante seis años consecutivos en la encuesta para desarrolladores de Stack Overflow .

    Al hablar sobre la decisión de construir Roma (la herramienta de construcción y no la ciudad) con Rust, Jamie Kyle dice:

    “Muchos otros han comunicado los beneficios de rendimiento, memoria y seguridad de Rust antes que nosotros; digamos que todos los que alguna vez han dicho que Rust es bueno tienen razón. Sin embargo, nuestra mayor preocupación era nuestra propia productividad. [...] Sin embargo, después de algunos prototipos, rápidamente nos dimos cuenta de que en realidad podríamos ser más productivos en Rust” Significado de los nombres

    — Jamie Kyle en Rome Will Be Written In Rust

    El proyecto SWC está a la vanguardia de esta idea de utilizar Rust para herramientas de construcción frontend. Ahora está impulsando proyectos como el nuevo compilador de Next.js, Deno, Parcel y otros, con un rendimiento que está muy por encima de otras herramientas de compilación existentes.

    Proyectos como SWC demuestran que con un cambio de plataforma subyacente, el rendimiento de las herramientas de compilación se puede mejorar significativamente.

     

    Un cambio de paradigma

    La forma en que funciona una canalización de compilación de frontend típica hoy en día es que usted crea módulos JavaScript en muchos archivos diferentes, ejecuta un comando, la herramienta de compilación recoge estos módulos, los agrupa en un solo módulo, los convierte a un formato comprendido por los navegadores y los sirve. archivo en el navegador.

    Para mejorar el rendimiento en el modo de desarrollo, muchas de las optimizaciones que tardarían más en completarse se omiten y, en su lugar, se ejecutan cuando agrupamos nuestra aplicación de producción. Esto garantiza que se necesite el menor tiempo posible para poner en marcha un servidor de desarrollo, ejecutar nuestra aplicación en modo de desarrollo y volverse productivo.

    Sin embargo, el proceso de agrupación todavía lleva bastante tiempo y, a medida que un proyecto crece, los tiempos de construcción (incluso en desarrollo) se hacen cada vez más largos. ¿No sería fantástico si de alguna manera pudiéramos omitir la agrupación y al mismo tiempo poder escribir módulos como de costumbre y hacer que el navegador entienda cómo trabajar con ellos? Un nuevo conjunto de herramientas de construcción está adoptando este enfoque, conocido como desarrollo desagregado.

    El desarrollo desagregado es genial. Resuelve un problema importante con las herramientas de compilación existentes: a menudo necesitan reconstruir secciones enteras de su aplicación incluso para cambios de código triviales, y los tiempos de compilación se hacen más largos a medida que la aplicación crece. Perdemos la retroalimentación rápida, esencial para una experiencia de desarrollo placentera.

    Uno podría preguntarse: si el desarrollo desagregado es tan grande, ¿por qué no es la norma hoy en día? Hay dos razones principales por las que el desarrollo desagregado apenas está comenzando a ganar terreno: la compatibilidad del navegador para funciones de vanguardia y el procesamiento de importaciones de módulos de nodos.

    1. Compatibilidad del navegador para funciones de vanguardia

    El desarrollo desagregado funciona con ES Modules (ESM), que brinda un sistema de módulos estandarizado a JavaScript, compatible de forma nativa en múltiples tiempos de ejecución, incluido el navegador. Con esta nueva capacidad, podemos marcar nuestras etiquetas de script como módulos y, en consecuencia, podemos usar las palabras clave importy exportcon las que todos estamos familiarizados;

    script type="module" src="main.js"/scriptscript type="module" /** JavaScript module code goes here *//script

    Los módulos ES existen desde hace bastante tiempo. Aun así, sólo podemos empezar a aprovecharlo para cosas como el desarrollo desagregado, principalmente debido al tiempo que llevó su estandarización en todos los actores del ecosistema web.

    En su artículo sobre ES Modules, en Mozilla Hacks, Lin Clark dice:

    “Los módulos ES aportan un sistema de módulos oficial y estandarizado a JavaScript. Sin embargo, tomó un tiempo llegar hasta aquí: casi 10 años de trabajo de estandarización”.

    - Lin Clark en Módulos ES: una inmersión profunda en dibujos animados

    El problema de la compatibilidad con el navegador o la falta de ella ha afectado al desarrollo frontend durante mucho tiempo. Esta es la razón por la que tenemos un prefijo de proveedor en nuestro CSS, a veces el motivo de los polyfills, por la que dedicamos tiempo a garantizar el soporte multiplataforma para nuestras aplicaciones web y por la que a veces lleva bastante tiempo antes de que podamos aprovechar las últimas y mejores funciones web. en nuestro día a día.

     

    Intente visitar un proyecto StackBlitz usando Safari y aparecerá la siguiente pantalla que informa la falta de soporte para WebContainers en navegadores no basados ​​en Chromium.

    Pruébelo usted mismo: este es el mensaje que recibirá cuando visite un proyecto StackBlitz en Safari. ( Vista previa grande )

    El ritmo de adopción de funciones no es el mismo entre los proveedores de navegadores y, a menudo, existen variaciones en la forma en que los diferentes proveedores implementan ciertas funciones. Sin embargo, el futuro parece prometedor con iniciativas como Interop 2022 .

    2. Procesamiento de importaciones de módulos de nodo

    La mayoría, si no todas, las aplicaciones frontend que escribimos hoy dependen de bibliotecas externas de NPM. Para una aplicación de reacción típica, importaríamos reaccionar en la parte superior de nuestros archivos componentes de esta manera:

    import React from 'react'/** The rest of your component code */

    Intentar cargar esto directamente en el navegador, como tendríamos que hacer para el desarrollo desagregado, generará dos problemas. En primer lugar, el navegador no sabe cómo resolver la ruta a buscar reacty, en segundo lugar, la biblioteca de reacción se publica como un módulo Common JS (CJS), que no se puede ejecutar de forma nativa en el navegador sin algún procesamiento previo.

    Este último es el problema más importante aquí, ya que es posible, e incluso trivial, simplemente reemplazar nuestras importaciones de módulos de nodos con rutas relativas a archivos específicos. Aún así, el hecho de que la mayoría de los paquetes NPM estén escritos en un formato de módulo más adecuado para Node JS que el navegador requiere que nuestras dependencias NPM sean tratadas especialmente para facilitar el desarrollo desagregado.

    Snowpack , en particular, maneja esto procesando las dependencias de la aplicación en archivos Javascript separados que luego se pueden usar directamente en el navegador. Puede encontrar más información sobre cómo Snowpack hace esto aquí .

    Ahora que los módulos ES son habituales en la mayoría de los navegadores modernos y existen soluciones alternativas inteligentes para las dependencias de NPM, las herramientas de compilación como Vite y Snowpack pueden ofrecer la opción de desarrollo desagregado con un rendimiento drásticamente mejorado, compilaciones ágiles y HMR súper rápido.

    Pensamientos finales

    El desarrollo del frontend ha recorrido un largo camino y nuestras necesidades evolucionan constantemente y aumentan en complejidad. Las herramientas de compilación son una parte esencial de la forma en que creamos aplicaciones frontend, y las herramientas existentes no están a la altura, lo que ha provocado el desarrollo de nuevas herramientas que reimaginan cómo se deben diseñar las herramientas de compilación.

    Con un gran enfoque en el rendimiento, la facilidad de uso y una configuración menos compleja, la próxima generación de herramientas de compilación está preparada para impulsar aplicaciones frontend ambiciosas durante algún tiempo.

    ¿Estás entusiasmado con los desarrollos recientes en este espacio? Déjame saber en los comentarios qué piensas sobre las próximas innovaciones y el panorama actual.

    Lecturas adicionales sobre la revista Smashing

    • “ Cómo mantener una aplicación Next.js de gran tamaño ”, Nirmalya Ghosh
    • “ Rompiendo compilaciones voluminosas con Netlify y Next.js ”, Átila Fassina
    • “ Comenzando con Webpack ”, Nwani Victory
    • “¿ Qué es esa herramienta (de desarrollo)? ”, Patricio Brosset

    (nl)Explora más en

    • javascript
    • Actuación
    • Herramientas de desarrollo





    Tal vez te puede interesar:

    1. 50 herramientas útiles de JavaScript
    2. 50 nuevas herramientas de JavaScript que mejorarán su flujo de trabajo
    3. Herramientas, bibliotecas y complementos útiles de JavaScript y jQuery
    4. Herramientas útiles de HTML, CSS y JavaScript que hacen prácticamente de todo

    El futuro de las herramientas de construcción frontend

    El futuro de las herramientas de construcción frontend

    ¡Registro! SmashingConf Friburgo 2024 Índice El pasado

    programar

    es

    https://aprendeprogramando.es/static/images/programar-el-futuro-de-las-herramientas-de-construccion-frontend-1147-0.jpg

    2024-04-04

     

    El futuro de las herramientas de construcción frontend
    El futuro de las herramientas de construcción frontend

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20