La próxima ola de frameworks web es BYOJS

La próxima ola de marcos de trabajo web es BYOJS.Hola, mi nombre es Brandon Roberts.Puedes seguirme en Twitter en Brandon T Roberts, donde publico gifs, hablo de deportes y a veces bloqueo a personas, así que puedes seguirme allí.Soy un mantenedor en el proyecto ngRx, que es un conjunto de bibliotecas reactivas para aplicaciones Angular.También soy un GDE, lo que significa que he estado en la comunidad de Angular durante un tiempo y he podido contribuir con algunas cosas interesantes allí.También soy un ingeniero de experiencia de desarrollo en App-Rite.

Entonces, para la agenda de esta charla, quiero cubrir la historia y evolución de la construcción de aplicaciones web y las diferentes pilas que he utilizado a lo largo de los años.Hablaré sobre la próxima ola de marcos de trabajo web y el significado de BYOJS.Y hablaré sobre lo que eso significa a través del proyecto Astro.

Primero hablaré sobre la historia y evolución de la construcción de aplicaciones web.Como mencioné antes, esto es desde mi punto de vista, que ha sido durante varios años.Tu experiencia puede variar aquí.Así que aclaremos eso desde el principio.Pero creo que tendremos algunas similitudes en el camino.Así que adentrémonos en la historia de la construcción de aplicaciones web.Tenemos aplicaciones tradicionales del lado del servidor, de las que hablaremos, aplicaciones del lado del cliente, y aplicaciones más modernas del lado del servidor antes de entrar en la próxima ola.

Para las aplicaciones tradicionales del lado del servidor, hablemos de algunas de ellas.Está PHP, que sigue siendo un favorito entre los desarrolladores.También hay otra opción clásica, ASP clásico, que es similar a PHP, pero utiliza una sintaxis mássimilar a .NET.También está .NET MVC, que es otro marco de trabajo de Microsoft utilizado para construir aplicaciones webcon una separación más clara entre modelo, vista y controlador.Express también surgió como una forma de servir una aplicación HTML utilizando varios lenguajes de plantillas.Por supuesto, hay muchos otros que surgieron en el camino.Estos marcos de trabajo del lado del servidor realizaban todo el procesamiento en el servidor y simplemente devolvían el HTML.Si había alguna funcionalidad de JavaScript en las páginas que estábamos construyendo, seagregaba más o menos como scripts en línea o archivos de JavaScript ligeramente empaquetados concatenadosjuntos.Esto se hacía generalmente utilizando la conocida biblioteca jQuery en ese entonces.

Ahora pasamos a las aplicaciones del lado del cliente.Cuando se introdujo más JavaScript en estas aplicaciones, comenzamos a vermás empaquetadores involucrados en el proceso para optimizar el envío de JavaScripta los usuarios.Herramientas de código abierto como Gulp, que es un conjunto de herramientas que utiliza un sistema de construcción en tiempo real.También está Browserify, que es una de las primeras herramientas que permitió a los desarrolladores utilizarmódulos en estilo Node.js y compilarlos y usarlos en el navegador.Require.js, que es un sistema de carga de módulos y archivos que también utiliza importaciones en estilo Node.js.

Y System.js, donde se utilizaban módulos ES estándar que podían cargarse en el navegador. Y con la evolución de las aplicaciones web construidas para aplicaciones del lado del cliente, surgieron más marcos de trabajo web en el camino. Backbone, que fue un marco MVC temprano para construir aplicaciones del lado del cliente. Está Ember, que se basa en gran medida en convenciones e integraciones para construir aplicaciones web. Estaba AngularJS, que se integraba con HTML existente con cosas como directivas. Angular, su sucesor, que se orientaba a aplicaciones más generales. React, introducido en 2013, que realmente cambió la forma en que pensamos en la construcción de interfaces de usuario en JavaScript. Y está Vue, que ha surgido y ha abierto su propio camino como una herramienta para construir aplicaciones web. Y, por supuesto, hay muchos otros marcos de trabajo web que han surgido en este espacio.

Para las aplicaciones modernas del lado del servidor que se construyeron en JavaScript, en el espacio de React tenemos opciones como Next.js, que es el marco de trabajo de React más grande hasta la fecha para construir aplicaciones. Y recién llegados a este espacio como Remix, que combina algunas cosas del cliente y del servidor de una manera más cohesiva. En el espacio de Angular tenemos cosas como Universal. Angular Universal para renderizar aplicaciones del lado del cliente en el servidor. Y para Vue tenemos herramientas como Nuxt y también hay otras en este espacio.

Las aplicaciones modernas de JavaScript también trajeron la necesidad de sistemas de construcción másadvanced. Y así, algunos de estos sistemas facilitaron el empaquetado de JavaScript para enviarlo al cliente. Y esto también facilitó el envío de aplicaciones completas del lado del cliente. Webpack probablemente sea el más notable hasta la fecha, con su amplio conjunto de complementos y personalización al igual que Rollup, que es un paquete de módulos para JavaScript que compila pequeñas piezas de código en algo más grande como una biblioteca o una aplicación. También está V, que ha llegado y ha arrasado en el panorama web con su velocidad y extensibilidad a través de complementos, y también se basa en Rollup y está construido en un lenguaje diferente, pero se utiliza para construir aplicaciones JavaScript. Si estás en el espacio de monorepo, hay herramientas como Lerna, que orquesta las herramientas de construcción, y ha estado presente durante varios años, y herramientas como NX que han modernizado el desarrollo de monorepos de código abierto. Y también hay otras en este espacio que han surgido como sistemas de construcción o herramientas para ayudar a los desarrolladores a enviar aplicaciones web. Porque al final del día, solo queremos volver a enviar código y aplicaciones a los usuarios y brindarles una buena experiencia de usuario. Así que a continuación, hablaré sobre la próxima ola de marcos de trabajo web y formas de enviar JavaScript, enviar aplicaciones con JavaScript que han surgido. Así que podemos comenzar con el por qué ha habido un cambio en las aplicaciones tradicionales del lado del servidor para enviar solo o la mayoría de las aplicaciones utilizando JavaScript y obtener algunas de las nuevas herramientas que están disponibles. Una cosa que realmente ha surgido es la idea de nuestras herramientas que te permiten medir el rendimiento de las aplicaciones web y brindarte más información sobre ese proceso. También está el surgimiento de la pila Jam, que analiza cuál es la definición de eso y cómo funcionan las diferentes herramientas en ese espacio. En lo que llamamos, al menos para esta charla, la web de primer nivel estático o basada en HTML. Tenemos herramientas que miden qué tan rápido y cuánto tiempo tarda en cargarse una página. También hay muchas herramientas conocidas. Estoy utilizando web.dev como referencia para las métricas que utilizamos para medir esto.

Whitehouse es una herramienta que también puedes utilizar para medir el rendimiento web de una aplicación. Y solo estoy enumerando algunas de las métricas que puedes utilizar para hacer eso. Hay tiempo de primer byte, que es una métrica que mide el tiempo entre la solicitud de un recurso y cuando el primer byte de la respuesta comienza a llegar. Hay primera pintura de contenido, que mide el tiempo desde que la página comienza a cargarse hasta que se renderiza cualquier parte del contenido de la página en la pantalla. También hay pintura de contenido más grande, que es una métrica importante centrada en el usuario para medir la velocidad de carga percibida, porque marca el punto en el que la página carga, en la línea de tiempo de carga de la página, cuando es probable que se haya cargado el contenido principal de la página. También está la métrica de tiempo de interacción, que mide cuándo comienza a cargarse la página, cuándo se han cargado sus principales subrecursos y el usuario es capaz de responder a la entrada del usuario. Por lo tanto, el uso de estas herramientas y métricas nos ha permitido obtener mejores conocimientos sobre cómo estamos utilizando o sobreutilizando JavaScript en las aplicaciones. Paquetes más grandes significan más JavaScript para procesar y HTML siempre ha sido la forma más rápida de enviar contenido a los usuarios. Por lo tanto, queríamos buscar una mejor combinación allí. Entonces, ¿cuáles son algunas de las próximas herramientas en la próxima ola de construcción de aplicaciones con JavaScript? Tenemos Jamstack y hablaré sobre qué es Jamstack y cómo proporciona algunas herramientas para construir aplicaciones web con JavaScript. Hablaré sobre SSG o generadores de sitios estáticos. Hablaré sobre el renderizado del lado del servidor. Y luego hablaremos sobre las aplicaciones web estáticas o basadas en HTML que están surgiendo o los marcos de trabajo que están surgiendo ahora para ayudarnos a enviar código.

Entonces tenemos el Jamstack, y la definición del Jamstack ha evolucionado a lo largo de los años. Al principio, se parecía más a esto, donde el Jam y Jamstack estaban en mayúsculas y se referían a usar JavaScript para mejorar páginas, APIs y, lo más común, funciones sin servidor para descargar datos, obtener del cliente o integrar más código en el cliente y, por supuesto, HTML para renderizar contenido en una página.

Hoy en día, Jamstack se define más como una arquitectura diseñada para hacer que la web sea más rápida, segura y fácil de escalar. Se basa en muchas de las herramientas y flujos de trabajo que los desarrolladores utilizan para ayudarlos a ser más productivos. Y eso es solo lo que se encuentra en la página jamstack.org para la definición.

Los generadores de sitios estáticos se centran en la pre-renderización, donde las páginas se renderizan en tiempo de compilación y se sirven en el cliente sin ningún HTML incluido. En Jamstack, también se centran en desacoplar APIs y servicios de las aplicaciones del lado del cliente y mejorar estas páginas con JavaScript porque el HTML ya está renderizado en lugar de usar JavaScript para renderizar la página en su totalidad. También existen aplicaciones renderizadas en el lado del servidor que se encuentran en este espacio, donde la pre-renderización se realiza en el servidor y luego se envía al cliente. Después de que se renderiza la página, se carga el JavaScript del lado del cliente y se hidrata la página para hacerla más interactiva. Aquí es donde aún enviamos uno o tal vez algunos paquetes al cliente para manejar esto en la aplicación del lado del cliente. Como mencioné antes, esto proporciona un tiempo de interacción más rápido si estamos midiendo el rendimiento de la página en sí. Cada una de estas herramientas se ha movido en esa dirección de tratar de obtener el contenido y los datos lo más rápido posible al cliente. También debo mencionar que HTML siempre ha sido la forma más rápida de llegar allí. Entonces, estas nuevas herramientas se están moviendo hacia lo que se llama una web de HTML primero o una web de HTML primero, donde la forma principal es renderizar HTML y luego agregar algo de JavaScript de diferentes maneras, o incluso no agregar JavaScript en absoluto, para los diferentes tipos de sitios web que se van a construir.

Algunas de estas herramientas incluyen QUIC, que es un marco de trabajo de HTML primero relativamente nuevo que renderiza todo el HTML utilizando SSR y solo, a un nivel muy granular, genera el JavaScript que necesitas. También está Spellkit, que utiliza la renderización en el lado del servidor con mejora progresiva para mejorar la página, donde aún obtienes los beneficios de HTML primero y con la funcionalidad adicional. También está Eleventy, que se creó como una alternativa de JavaScript a Jekyll. Esto también no envía JavaScript del lado del cliente por adelantado. Otra herramienta que descubrí recientemente se llama Eels, que es nueva en este espacio, y luego está Astro, del cual hablaré más. Es una herramienta de generación de sitios estáticos que tiene integraciones adicionales. Como mencioné antes, Eels es relativamente nuevo y se inspiró en Astro. Pero lo más importante que queremos aquí es un equilibrio donde aún podamos ofrecer contenido a los usuarios lo más rápido posible al tiempo que brindamos una experiencia de usuario rica para las aplicaciones web.

A continuación, quiero hablar sobre esta nueva web de HTML primero a través del proyecto Astro. Astro es un generador de sitios estáticos que también ha agregado recientemente soporte para renderizado en el lado del servidor. No envía JavaScript del lado del cliente por defecto cuando está renderizando las páginas de la aplicación en tu sitio web. Promueve cosas como la arquitectura de islas y utiliza la hidratación parcial, de lo cual hablaré más y tiene integraciones. Y luego hablaremos sobre lo que eso significa en el mundo de BYOJS, como lo llamo. El generador de sitios estáticos se ocupa principalmente de sitios web, por lo que estás construyendo cosas como páginas de destino, sitios de marketing. También hay blogs, cosas que no requieren mucha interactividad del usuario o tal vez solo un poco de actividad del usuario, interactividad y simplemente hacer una diferenciación general entre sitios web y aplicaciones web.

Como mencioné antes, Astra no envía JavaScript por defecto. Por lo tanto, utiliza el renderizado en el lado del servidor o el renderizado en el lado del usuario para renderizar estos componentes en la página. Lo hace eliminando todo el JavaScript al renderizar la página en el momento de la compilación y enviándote solo el marcado para que puedas usarlo con tus estilos y presentar esos datos al usuario.

Como mencioné antes, Astra admite la hidratación parcial. Por lo tanto, hay áreas donde necesitarás algo de interactividad. Lo logra proporcionando o cargando solo lo necesario para el cliente en ese momento específico. Cada componente específico tiene una cierta funcionalidad de JavaScript, como un carrusel de imágenes, una barra de búsqueda con autocompletado o incluso una barra lateral móvil. Estas son cosas que se renderizan en el cliente y aún quieres tener algo de JavaScript allí para mejorar esa experiencia.

Como mencioné antes, la arquitectura de islas es la idea de utilizar la hidratación parcial para construir sitios web completos. Esto es una alternativa al proceso común de construir un sitio web, como un paquete en JavaScript y enviar ese paquete completo al usuario, ya sea un solo paquete o tal vez algunos paquetes cargados de forma diferida. Pero aún así, todos estos componentes se cargan de forma individual para el sitio web o tal vez una pequeña aplicación web en sí. Y todas estas cosas se cargan de forma aislada, es decir, no están conectadas entre sí de ninguna manera, por lo que no tienen ninguna dependencia de lo que se necesita cargar para ellos.

Al mirar una página de ejemplo, tenemos algunas áreas distintas. Podríamos tener una cabecera donde la cabecera se carga de forma independiente en su propia isla. Una barra de navegación en el lateral que puede tener sus propios subcomponentes y el área principal para mostrar contenido en la página. Como mencioné antes, todas estas cosas se consideran islas y se cargan de forma aislada e independiente entre sí.

La arquitectura de islas o los componentes en la arquitectura de islas también hacen uso de diferentes directivas. Estas son directivas que, cuando se utilizan en los componentes, indican cuándo cargar el componente cuando la página se carga, para no cargar el JavaScript hasta que el componente esté presente en la página. O si el usuario está navegando por la página y está inactivo, entonces cargar esos componentes. Definitivamente se aprovecha de diferir eso tanto como sea posible para mostrarlo o cargar ese JavaScript para el usuario.

Entonces, ¿qué significa esto en términos de BYO JS que he estado mencionando durante esta charla? BYO JS significa traer tu propio framework de JavaScript, incluido allí. Y Astro lo hace a través de integraciones. Astro es diferente porque puedes utilizar tus conocimientos existentes de tu framework elegido y Astro sabe cómo integrarse con esos frameworks web y renderizar esos componentes en la página de forma estática. Y agregar interactividad a esos componentes más tarde cuando lo necesites en el cliente, por lo que obtienes lo mejor de ambos mundos.

Astro admite casi todos los frameworks comúnmente utilizados que admiten componentes, como React, Vue, Svelte, Solid y más. Hay más que solo mencioné aquí. También tienen APIs que te permitirían integrar cualquier framework de JavaScript en una aplicación de Astro. Puedes obtener más información sobre el proyecto Astro en astro.build. Puedes leer más en la documentación, aprender más sobre las integraciones y ver cómo puede ayudarte a construir sitios web más rápido. Así que definitivamente échale un vistazo. En resumen, hablé sobre la historia y evolución de la construcción de aplicaciones web, utilizando el renderizado en el lado del servidor, el lado del cliente y las aplicaciones y frameworks. Hablé sobre la próxima ola de frameworks web, algunos de los cuales están disponibles hoy en día, como el uso de Jamstack y otras herramientas en ese espacio. Y hablé sobre el proyecto Astro. Puedes obtener más información sobre Astro en astro.build para leer más sobre la documentación y obtener más información o incluso participar en el proyecto.