Qué resuelven los frameworks web y cómo prescindir de ellos (Parte 1)

 

 

 

  • Accesibilidad para diseñadores, con Stéphanie Walter
  • SmashingConf Friburgo 2024

  • Índice
    1. Los marcos
    2. Qué resuelven los marcos
      1. Programación declarativa
      2. El enlace de datos
      3. Reactividad
      4. Lógica
      5. Modelo de componente
    3. El costo
      1. Tamaño del paquete
      2. construye
      3. Depuración
      4. Actualizaciones
    4. Resumen

    En este artículo, Noam Rosenthal profundiza en algunas características técnicas que son comunes entre los marcos y explica cómo algunos de los diferentes marcos las implementan y cuánto cuestan.

     

    Recientemente me he interesado mucho en comparar marcos con JavaScript básico. Comenzó después de cierta frustración que sentí al usar React en algunos de mis proyectos independientes y con mi conocimiento reciente y más íntimo de los estándares web como editor de especificaciones.

    Me interesaba ver cuáles son los puntos en común y las diferencias entre los marcos , qué tiene para ofrecer la plataforma web como alternativa más sencilla y si es suficiente. Mi objetivo no es criticar los marcos, sino más bien comprender los costos y beneficios, determinar si existe una alternativa y ver si podemos aprender de ella, incluso si decidimos utilizar un marco.

    En esta primera parte, profundizaré en algunas características técnicas comunes a todos los marcos y cómo algunos de los diferentes marcos las implementan. También analizaré el costo de usar esos marcos.

    Los marcos

    Elegí cuatro marcos para analizar: React, que es el dominante hoy en día, y tres contendientes más nuevos que afirman hacer las cosas de manera diferente a React.

    • React
      “React hace que sea sencillo crear interfaces de usuario interactivas. Las vistas declarativas hacen que su código sea más predecible y más fácil de depurar”.
    • SolidJS
      "Solid sigue la misma filosofía que React... Sin embargo, tiene una implementación completamente diferente que renuncia al uso de un DOM virtual".
    • Svelte
      “Svelte es un enfoque radicalmente nuevo para crear interfaces de usuario... un paso de compilación que ocurre cuando creas tu aplicación. En lugar de utilizar técnicas como la diferenciación de DOM virtual, Svelte escribe código que actualiza quirúrgicamente el DOM cuando cambia el estado de su aplicación”.
    • Lit
      "Basándose en los estándares de componentes web, Lit añade simplemente... reactividad, plantillas declarativas y un puñado de características bien pensadas".

    Para resumir lo que dicen los marcos sobre sus diferenciadores:

     

    • React facilita la creación de interfaces de usuario con vistas declarativas.
    • SolidJS sigue la filosofía de React pero utiliza una técnica diferente.
    • Svelte utiliza un enfoque en tiempo de compilación para las UI.
    • Lit utiliza estándares existentes, con algunas características livianas adicionales.

    Qué resuelven los marcos

    Los propios marcos mencionan las palabras declarativo, reactividad y DOM virtual. Profundicemos en lo que significan.

    Programación declarativa

    La programación declarativa es un paradigma en el que la lógica se define sin especificar el flujo de control. Describimos cuál debe ser el resultado, en lugar de qué pasos nos llevarían allí.

    En los primeros días de los marcos declarativos, alrededor de 2010, las API DOM eran mucho más simples y detalladas, y escribir aplicaciones web con JavaScript imperativo requería una gran cantidad de código repetitivo. Fue entonces cuando el concepto de " modelo-vista-modelo " (MVVM) se volvió frecuente, con los entonces innovadores marcos Knockout y AngularJS, que proporcionaban una capa declarativa de JavaScript que manejaba esa complejidad dentro de la biblioteca.

    MVVM no es un término muy utilizado hoy en día y es una especie de variación del antiguo término "enlace de datos".

    El enlace de datos

    El enlace de datos es una forma declarativa de expresar cómo se sincronizan los datos entre un modelo y una interfaz de usuario.

    Todos los marcos de UI populares proporcionan algún tipo de enlace de datos y sus tutoriales comienzan con un ejemplo de enlace de datos.

    Aquí está el enlace de datos en JSX (SolidJS y React):

    function HelloWorld() { const name = "Solid or React"; return ( divHello {name}!/div )}

    Enlace de datos en literatura:

    class HelloWorld extends LitElement { @property() name = 'lit'; render() { return html`pHello ${this.name}!/p`; }}

    Enlace de datos en Svelte:

    script let name = 'world';/scripth1Hello {name}!/h1

    Reactividad

    La reactividad es una forma declarativa de expresar la propagación del cambio.

    Cuando tenemos una forma de expresar declarativamente el enlace de datos, necesitamos una forma eficiente para que el marco propague los cambios.

    El motor React compara el resultado del renderizado con el resultado anterior y aplica la diferencia al propio DOM. Esta forma de manejar la propagación de cambios se llama DOM virtual .

    En SolidJS, esto se hace de forma más explícita, con su tienda y elementos integrados. Por ejemplo, el Showelemento realizaría un seguimiento de lo que ha cambiado internamente, en lugar del DOM virtual.

     

    En Svelte, se genera el código "reactivo". Svelte sabe qué eventos pueden provocar un cambio y genera un código sencillo que traza la línea entre el evento y el cambio DOM.

    En Lit, la reactividad se logra utilizando propiedades de elementos, basándose esencialmente en la reactividad incorporada de los elementos personalizados HTML.

    Lógica

    Cuando un marco proporciona una interfaz declarativa para el enlace de datos, con su implementación de reactividad, también necesita proporcionar alguna forma de expresar parte de la lógica que tradicionalmente se escribe de manera imperativa. Los componentes básicos de la lógica son "si" y "para", y todos los marcos principales proporcionan alguna expresión de estos componentes. Recetas faciles y rápidas

    Condicionales

    Además de vincular datos básicos como números y cadenas, cada marco proporciona una primitiva "condicional". En React, se ve así:

    const [hasError, setHasError] = useState(false); return hasError ? labelMessage/label : null;…setHasError(true);

    SolidJS proporciona un componente condicional integrado Show:

    Show when={state.error} labelMessage/label/Show

    Svelte proporciona la #ifdirectiva:

    {#if state.error} labelMessage/label{/if}

    En Literatura, usarías una operación ternaria explícita en la renderfunción:

    render() { return this.error ? html`labelMessage/label`: null;}

    Liza

    La otra primitiva del marco común es el manejo de listas. Las listas son una parte clave de las interfaces de usuario (lista de contactos, notificaciones, etc.) y, para funcionar de manera eficiente, deben ser reactivas y no actualizar toda la lista cuando cambia un elemento de datos.

    En React, el manejo de listas se ve así:

    contacts.map((contact, index) = li key={index} {contact.name} /li)

    React usa el keyatributo especial para diferenciar entre los elementos de la lista y se asegura de que la lista completa no sea reemplazada con cada renderizado.

    En SolidJS, se utilizan los elementos integrados fory :index

    For each={state.contacts} {contact = DIV{contact.name}/DIV }/For

    Internamente, SolidJS utiliza su propia tienda junto con fory indexpara decidir qué elementos actualizar cuando cambian. Es más explícito que React, lo que nos permite evitar la complejidad del DOM virtual.

    Svelte usa la eachdirectiva, que se transpila según sus actualizadores:

    {#each contacts as contact} div{contact.name}/div{/each}

    Lit proporciona una repeatfunción que funciona de manera similar al keymapeo de listas basado en React:

     

    repeat(contacts, contact = contact.id, (contact, index) = html`div${contact.name}/div`

    Modelo de componente

    Una cosa que está fuera del alcance de este artículo es el modelo de componente en los diferentes marcos y cómo se puede abordar utilizando elementos HTML personalizados.

    Nota : Este es un tema extenso y espero cubrirlo en un artículo futuro porque sería demasiado largo. 🙂

    El costo

    Los marcos proporcionan enlace de datos declarativo, primitivas de flujo de control (condicionales y listas) y un mecanismo reactivo para propagar cambios.

    También proporcionan otras cosas importantes, como una forma de reutilizar componentes, pero ese es un tema para un artículo aparte.

    ¿Son útiles los marcos? Sí. Nos brindan todas estas características convenientes. ¿Pero es esa la pregunta correcta? El uso de un marco tiene un costo. Veamos cuáles son esos costos.

    Tamaño del paquete

    Cuando miro el tamaño del paquete, me gusta mirar el tamaño minimizado sin Gzip. Ese es el tamaño más relevante para el costo de CPU de la ejecución de JavaScript.

    • ReactDOM tiene aproximadamente 120 KB.
    • SolidJS pesa aproximadamente 18 KB.
    • Encendido es de unos 16 KB.
    • Svelte pesa aproximadamente 2 KB, pero el tamaño del código generado varía.

    Parece que los marcos actuales están haciendo un mejor trabajo que React al mantener pequeño el tamaño del paquete. El DOM virtual requiere mucho JavaScript.

    construye

    De alguna manera nos acostumbramos a "construir" nuestras aplicaciones web. Es imposible iniciar un proyecto front-end sin configurar Node.js y un paquete como Webpack, lidiar con algunos cambios de configuración recientes en el paquete de inicio Babel-TypeScript y todo eso.

    Cuanto más expresivo y pequeño sea el tamaño del paquete del marco, mayor será la carga de las herramientas de compilación y el tiempo de transpilación.

    Svelte afirma que el DOM virtual es pura sobrecarga . Estoy de acuerdo, pero ¿tal vez la “construcción” (como con Svelte y SolidJS) y los motores de plantillas personalizados del lado del cliente (como con Lit) también sean pura sobrecarga, de un tipo diferente?

    Depuración

    La construcción y la transpilación conllevan un tipo de costo diferente.

    El código que vemos cuando usamos o depuramos la aplicación web es totalmente diferente al que escribimos. Ahora confiamos en herramientas de depuración especiales de diversa calidad para aplicar ingeniería inversa a lo que sucede en el sitio web y conectarlo con errores en nuestro propio código.

    En React, la pila de llamadas nunca es "tuya": React maneja la programación por usted. Esto funciona muy bien cuando no hay errores. Pero intenta identificar la causa de las re-renderizaciones de bucle infinito y te encontrarás con un mundo de dolor.

    En Svelte, el tamaño del paquete de la biblioteca en sí es pequeño, pero vas a enviar y depurar una gran cantidad de código críptico generado que es la implementación de reactividad de Svelte, personalizado según las necesidades de tu aplicación.

    Con Lit, no se trata tanto de construir, sino de depurarlo de manera efectiva, debes entender su motor de plantillas. Esta podría ser la razón principal por la que mi sentimiento hacia los marcos es escéptico.

    Cuando busca soluciones declarativas personalizadas, termina con una depuración imperativa más dolorosa. Los ejemplos de este documento utilizan Typecript para la especificación de API, pero el código en sí no requiere transpilación.

    Actualizaciones

    En este documento, analicé cuatro marcos, pero hay más marcos de los que puedo contar (AngularJS, Ember.js y Vue.js, por nombrar algunos ) . ¿Puede contar con que el marco, sus desarrolladores, su mentalidad y su ecosistema trabajarán para usted a medida que evoluciona?

    Una cosa que es más frustrante que corregir tus propios errores es tener que encontrar soluciones para los errores del marco. Y una cosa que es más frustrante que los errores del marco son los errores que ocurren cuando actualizas un marco a una nueva versión sin modificar tu código.

    Es cierto que este problema también existe en los navegadores, pero cuando ocurre, le sucede a todos y, en la mayoría de los casos, una solución o una solución alternativa publicada es inminente. Además, la mayoría de los patrones de este documento se basan en API de plataformas web maduras; No siempre es necesario ir a la vanguardia.

    Resumen

    Profundizamos un poco más en la comprensión de los problemas centrales que los marcos intentan resolver y cómo los resuelven, centrándonos en el enlace de datos, la reactividad, los condicionales y las listas. También analizamos el costo.

    En la Parte 2 , veremos cómo se pueden abordar estos problemas sin utilizar ningún marco y qué podemos aprender de él. ¡Manténganse al tanto!

    Un agradecimiento especial a las siguientes personas por sus revisiones técnicas: Yehonatan Daniv, Tom Bigelajzen, Benjamin Greenbaum, Nick Ribal y Louis Lazaris.

    (vf, il, al)Explora más en

    • Reaccionar
    • Marcos
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Qué resuelven los frameworks web y cómo prescindir de ellos (Parte 1)

    Qué resuelven los frameworks web y cómo prescindir de ellos (Parte 1)

    Accesibilidad para diseñadores, con Stéphanie Walter SmashingConf Friburgo 2024 Índice Los marcos

    programar

    es

    https://aprendeprogramando.es/static/images/programar-que-resuelven-los-frameworks-web-y-como-prescindir-de-ellos-parte-1-1129-0.jpg

    2024-04-04

     

    Qué resuelven los frameworks web y cómo prescindir de ellos (Parte 1)
    Qué resuelven los frameworks web y cómo prescindir de ellos (Parte 1)

    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