Hidratación, Islas, Streaming, Reanudabilidad... ¡Oh Dios Mío!

Entonces, hola, Londres. Es genial estar aquí en esta increíble conferencia de nuevo. Y, sí, soy Mathias Apkarky, y hoy estamos aquí para discutir sobre hidratación, islas, streaming, reanudabilidad, y, wow, probablemente deberíamos empezar, ¿verdad?

Entonces esto es lo que queremos cubrir hoy. Hablaremos un poco sobre el pasado y el futuro de las cosas. Y luego iremos a las islas, reanudabilidad. También hablaremos sobre streaming SSR y cómo se combina con la hidratación selectiva. Deberíamos hablar sobre los React componentes de servidor, ¿verdad? Y luego redactaremos algunos pensamientos finales sobre las cosas.

Y empecemos con la hidratación porque, sí, queremos cubrir eso. Entonces, si no estás familiarizado, me encanta esta definición de Mishko, que la hidratación es el proceso de adjuntar comportamiento a contenido declarativo para hacerlo interactivo. Y la hidratación viene con algunos desafíos. Entonces, primero, y obviamente tienes que asociar los elementos DOM con sus correspondientes manejadores de eventos. Pero también como usuario, por ejemplo, activa uno de estos manejadores, quieres actualizar el estado de tu aplicación. Y no solo eso, sino que una vez que se actualiza el estado, tu marco necesita recrear la jerarquía DOM y todo. Entonces, la hidratación viene con desafíos y también con problemas. Y ese es uno de los más comunes. Se llama el valle inquietante. Y sucede exactamente, entonces tienes tu solicitud inicial, tienes tu HTML y luego tienes tu vista pintada, pero luego tienes que esperar a que llegue, se ejecute, se analice y todo. Entonces, el valle inquietante es este momento en el que todo está pintado, pero no tienes interacción, lo cual es malo. Y si lo desglosamos, todo comienza, por ejemplo, cuando obtenemos el HTML. Y eso es generalmente rápido, por supuesto, pero luego tienes que descargar JavaScript, y eso puede ser lento dependiendo de las condiciones de red de tus usuarios, como probablemente sepas. También tienes que analizar y ejecutar JavaScript. Y eso también puede ser lento dependiendo de las capacidades de los dispositivos de tus usuarios. Y también en la cantidad de JavaScript que estás enviando por la red. Y por último, pero no menos importante, tu marco también tiene que recuperar, estado, y vincular todos los oyentes. Y eso puede ser lento dependiendo, por ejemplo, de la cantidad de nodos hechos que necesitas atravesar. Y también la cantidad de referencias que necesitas volver a vincular a esos oyentes. Podríamos estar aquí todo el día hablando sobre los desafíos y los problemas con la hidratación, y también tienes muchos posts interesantes por ahí. Pero el punto es que, a lo largo de los años, la gente intentaba pensar en formas creativas para solucionar o abordar, al menos una parte de estos problemas. Y fue en 2020 que empezamos a escuchar mucho sobre el término islas desconectadas. Y obtuvimos este nombre de este post de Jason Miller, el creador de React y también el creador de otras cosas increíbles de código abierto.

Pero si retrocedemos un poco en el tiempo, encontramos publicaciones como esta. Se llama Componentes JS Declarativos con Vloader.js. Y fue publicado en 2013, y trataba sobre la idea de adjuntar comportamiento JS a fragmentos de HTML. Así que puedes ver que la gente estaba pensando en algo así.

Y eso es lo que son las islas. Estás mejorando selectiva y progresivamente partes del HTML renderizado en el servidor con algo de JavaScript del lado del cliente. Y tienes pequeños fragmentos de interactividad enfocados dentro de esas páginas SSR. Y es un poco un cambio de mentalidad, porque estás pasando de este modelo donde tienes una única aplicación en control de la renderización completa de la página. A un lugar donde tienes múltiples puntos de entrada. Además, normalmente con una isla, este script para las islas puede ser entregado e hidratado de forma independiente. Y permite que el resto de la página sea solo HTML estático. Pero a diferencia de otros enfoques de hidratación progresiva aquí, tienes más especificidad en cómo ocurre esta mejora.

Otra cosa genial de las islas es que hoy en día tenemos muchas formas de aprovecharlas, así que tenemos implementaciones independientes como Astro, Quake, Markle, y muchas otras. Y también puedes usar diferentes herramientas para hacer islas con Preact, con Solid, con Svelte. Y una cosa interesante de las islas es Markle. Así que Markle estuvo ahí desde 2014, fue de código abierto unos años después. Pero Markle vino con esta combinación muy interesante de streaming, con hidratación parcial automática, y un compilador inteligente que básicamente generaría código optimizado dependiendo de dónde iba a ejecutarse en el cliente y en el servidor. Markle también tenía hidratación parcial automática que básicamente permitía a esos componentes interactivos hidratarse a sí mismos. Y el código de hidratación, por supuesto, solo se enviaba para los componentes que necesitaban interacción. Años después, llegó Astro, y la mayoría de ustedes han oído hablar de Astro, así que en 2021. Y Astro de nuevo tenía una combinación muy interesante. Así que por defecto, estaba enviando 0 JavaScript, y cada isla podía ser cargada en paralelo. Markle también era multi-framework, así que podías construir islas con React, Preact, Vector, y muchos otros. Y Astro te permitía especificar la estrategia de carga para cada una de tus islas. Así que por ejemplo, si estás usando un componente JSX de React con Astro y lo estás importando, y etc., puedes hacer cosas como esta. Así que puedes especificar si eso va a ser hidratado al cargar o cuando el navegador esté inactivo o solo cuando tu componente se haga visible. Y puedes hacer cosas aún más complejas. Así que eso es lo genial de las islas en general. Estás reduciendo la cantidad de código JavaScript que se envía al cliente también puedes obtener cargas de página más rápidas y mejores métricas relacionadas con eso como TTI y otras. Y en general, estás haciendo que el contenido clave de tu sitio o tu aplicación esté disponible más rápido para el usuario.

Sin mencionar que estás obteniendo los beneficios tradicionales de SSR como una mejor SEO. Donde veo que las islas podrían no ser una buena opción es dependiendo de la cantidad de interactividad que tengas, podrías terminar con docenas o cientos de islas y entonces podrías estar perdiendo el punto.

También en 2021, obtuvimos la re-zoomabilidad. Y creo que una buena forma de pensar sobre el modelo de re-zoomabilidad es si imaginamos que muchas de las cosas que tenemos en el paisaje isomórfico estos días, comenzaron sobre frameworks que no fueron inicialmente pensados para eso. Entonces, por ejemplo, este es un post de 2013 donde el equipo de Airbnb estaba experimentando con la renderización en el servidor de backbone. Y si recordamos en ese momento, eso es principalmente lo que teníamos. La gente estaba experimentando con la renderización en el servidor Angular o React u otros frameworks. Pero ¿qué pasaría si hicieramos lo contrario? ¿Qué pasaría si esos frameworks, comenzaran con la renderización en el servidor en mente en primer lugar?

En 2011, tuvimos este lenguaje, OPA. ¿Alguien ha oído hablar de él? Okay, no nosotros. Una mano, wow. Entonces OPA fue más allá de solo la hidratación parcial. Básicamente escribías programas y el compilador dividiría las preocupaciones del cliente y del servidor para ti. Y eso fue asombroso. Años después, obtuvimos Meteor, que tenía algo de eso en mente y también obtuvo algo de tracción. Y en 2021, obtuvimos Quik, del cual probablemente la mayoría de ustedes han oído hablar. Esa es la idea de la reanudabilidad. Se trata de pausar la ejecución en el servidor y reanudar en los clientes sin tener que repetir y descargar toda la lógica de la aplicación. Así que eso es prácticamente todo. Hacer algo de trabajo, pausar, reanudar donde lo dejamos. Y utilizas lo que sucedió durante la ejecución en el servidor para evitar trabajo extra cuando la aplicación se inicia en el navegador. Además, lo hace adjuntando manejadores de eventos globales en el momento de inicio, pero solo los ejecuta cuando es necesario al interactuar. Si lo comparas con la hidratación tradicional, no estoy hablando de progresiva o selectiva, nada de eso, con la hidratación tradicional, tenemos un enfoque ansioso donde la creación del manejador de eventos ocurre antes de que estos sean llamados o activados. Además, las cosas son un poco más especulativas. Así que todos ellos son creados independientemente de si se usan o no. Y también tienes al cliente repitiendo el trabajo y el marco tiene que descargar y ejecutar los componentes para averiguar su jerarquía. Con la reanudabilidad, tienes lo contrario. Así que tienes un enfoque perezoso donde la creación del manejador de eventos ocurre después de que el evento es activado. Y también solo los eventos activados son los que se crean y registran. Así que esto ocurre según sea necesario. Además, el cliente no está repitiendo el trabajo porque aprovecha mucho la deserialización.

Así que sí, requiere mucha información importante para ser incluida en el HML. Si estás interesado, hay este gran stream con Ryan de Solid y Mischka donde idean toda la idea de la reanudabilidad durante un par de horas. Pero eso es lo que es genial de la reanudabilidad. Tiende a mejorar tu rendimiento de inicio performance y básicamente, también tu rendimiento de renderizado performance porque viene con otras ideas geniales como por ejemplo, solo el cambio de componentes se vuelve a renderizar. Además, trae una carga lenta y progresiva de interactividad.

Lo que me preocupa, sin embargo es que es una buena práctica precargar tus interacciones críticas de la página. Así que si resulta que tienes muchas interacciones críticas de la página, podrías tener que precargar muchas cosas. Además, la única opción que tenemos estos días para aprovechar la Reanudabilidad tal como está definida es QUIC. Así que la mayoría de las discusiones alrededor de ella están en la community QUIC y en builder.io, aunque algunas personas argumentarían que Marcoversion 6 trae algo similar a la Reanudabilidad. Pero de todos modos, tengo que decir que creo que QUIC es un ejemplo perfecto de pensamiento fuera de la caja que a veces es necesario para solucionar problemas en la web.

Al mismo tiempo, comenzó en 2017, pero ganó más tracción en 2022. Empezamos a hablar de transmitir cosas y luego la hidratación selectiva. Así que el Streaming-SSR fue realmente lanzado con React 16 y solo unos pocos de nosotros estábamos prestando mucha atención porque estábamos discutiendo hooks, Suspense, la nueva API de Contexto, y muchas otras cosas geniales que también sucedieron durante React 16. Algunas personas estaban aprovechando el Streaming-SSR en ese momento, pero ganó más tracción después, principalmente el año pasado, después de que se combinó con la Hidratación Selectiva y otras cosas geniales del paraguas de React Concurrente.

Y es bueno si vemos cómo sucedieron las cosas antes. Así que antes de React 18, la hidratación solo podía comenzar después de que se hubiera obtenido y renderizado toda la data para tu página. Así que por eso, tus usuarios, ellos no podían interactuar en la página hasta que el proceso de hidratación estuviera completo para todo eso. Y la conclusión aquí es que las partes de la aplicación que eran rápidas, terminaban teniendo que esperar a las lentas. Así que se ve así. Todos estos son pasos secuenciales y bloqueantes. Así que obtenemos la data en el servidor, renderizamos el HTML en el servidor, y luego obtenemos nuestro primer byte. Y luego lo cargamos en el cliente, y obtenemos nuestro FCP. Y solo después de hidratar, obtenemos nuestro primer, nuestro TTI. Con StreamySSR y hidratación selectiva, podemos convertir las cosas en esto. Y ahora, React va a priorizar la hidratación de las partes de la aplicación con las que el usuario interactuó antes que el resto de la página. Y debido a eso, los componentes, ellos pueden volverse interactivos más rápido permitiendo que la página haga otro trabajo, permitiendo que el navegador haga otro trabajo al mismo tiempo que la hidratación, porque es React Concurrente. Y por supuesto, React ya no tiene que esperar a que los componentes se carguen para continuar transmitiendo el HTML para el resto de la página. Y cuando esa parte específica esté disponible, será transmitida e insertada en el lugar correcto por Script Tag. Muchas empresas, por cierto, construyen casos interesantes alrededor de esto. Vercel tiene algunos números de cómo mejoraron el Next.js sitio web, algunos core web vitals en los sitios web de Next.js utilizando eso, incluyendo su INB.

Entonces, es posible que quieras echarle un vistazo. Y luego, un año después, también empezamos a oír hablar de los React componentes de servidor, lo cual es gracioso, porque si has estado siguiendo las discusiones, estuvo allí durante mucho tiempo bajo el nombre de React Flight. Así que acabamos de discutir las cosas de F, como olvidar. Fue React Flight en 2018, 19. Y luego, a finales de 2020, obtuvimos esta publicación que introducía los componentes de servidor de React de tamaño de paquete 0. Y después de eso, fue gran parte de la comunidad, nosotros, el equipo, como ¿cómo se une esto con suspense, transiciones, y etcétera? Así que en mi opinión, un buen enfoque para entender los componentes de servidor es pensar en ellos como si pudieras tener un renderizado anticipado que puede ocurrir durante el tiempo de construcción en un servidor. Pero también es un paradigma de enrutamiento que está realmente integrado con la obtención de datos e incluso con la forma en que agrupas las cosas. Y como puede parecer, no está necesariamente relacionado con SSR o incluso con la hidratación. Dado que discutimos las islas, podemos decir que en realidad RSC es realmente idéntico a cómo funcionan las islas. Pero lo cierto es que cuando estábamos haciendo islas con Astro, por ejemplo, teníamos un límite claro, qué es Astro y qué es React. Con los componentes de servidor, no lo tenemos. Por eso tenemos cosas como used client. Used client está marcando un límite entre estos dos gráficos de módulos, el del servidor y el del cliente. Y por supuesto, con RSC, cada componente puede decidir si va a ser un componente de servidor o un componente de servidor más cliente. Y creo que tres cosas son increíbles sobre los RSC. La primera y, por supuesto, probablemente lo que más oyes es que el código para los componentes del servidor nunca se envía al cliente, lo cual es realmente genial porque en muchas implementaciones de SSR que tenemos hoy en día, terminamos teniendo código embotellado y enviado a través del cable. La segunda cosa es que obtienes acceso al backend desde cualquier lugar dentro del árbol. Y mucha gente ve esto como algo malo, pero en realidad, es increíble. Imagina lo que haces con Next.js, por ejemplo, que a nivel de página, tienes cosas como get server side props, pero ahora desde cualquier lugar dentro del árbol. Y la tercera cosa es probablemente lo que más me gusta es que, esos pueden ser reobtenidos mientras se mantiene el estado del lado del cliente dentro del árbol. Así que piensa en un componente de entrada que puedes refrescar, volver a renderizar, pero mantener, enfocar, pasar el ratón por encima, ese tipo de cosas. Así que Ben preparó un ejemplo realmente bueno en este post de RC desde cero. Así que este es un ejemplo de navegación sin componentes de servidor. Y puedes ver que cuando navegas, pierdes el estado. Y aquí está la misma cosa, pero con componentes de servidor. Y puedes ver que navegas. Y el estado no se pierde. Lo que me preocupa de los componentes de servidor es que tal vez podríamos tener situaciones donde obtenemos muchos datos enviados a través del cable en cada re-renderizado. También, tanto desde la perspectiva de los constructores de marcos, como de los constructores de aplicaciones, esta orquestación de cómo va a funcionar esto. Y la experiencia final del desarrollador para mí todavía está borrosa.

Pero muchas cosas sobre esto todavía son experimentales, al final. Y tienes pocas opciones para aprovechar los RSCs, principalmente Next.js con el enrutador de la aplicación. Pero para mí, los RSCs traen una discusión muy, muy interesante que es esta cosa de co-localizar el cliente y el código del servidor, y cómo eso probablemente va a ser el futuro. Y me recuerda mucho a esta cosa llamada JacksR. ¿Alguien aquí conoce JacksR? Genial. Nadie. Así que JacksR estaba aquí en 2008. Y aquí están algunos de los ejemplos oficiales de uso de JacksR. Pero quiero destacar esta etiqueta de script donde tenías este atributo runAt. Y podrías especificar, por ejemplo, runAt server o runAt both. Y si pones lado a lado la documentación de esa biblioteca de 2008 y la última documentación, por ejemplo, con componentes de servidor, verás algunas similitudes. Por supuesto, no son la misma cosa, pero puedes ver que la idea de intentar coordinar los dos estaba allí. De todos modos, creo que muchos de nosotros, incluyéndome a mí, todavía necesitamos aprender mucho sobre los componentes del servidor. Tuvimos sesiones muy interesantes. Después de mí, viene Tejas, y estoy bastante seguro de que lo va a cubrir muy bien también. Hay muchas transmisiones en vivo sobre el tema que podrías querer ver, y también muchos proyectos paralelos interesantes que lo involucran. Wacoo, de Dai Shikado, es uno de ellos. Donde básicamente está construyendo su propia implementación de RSCs. E incluso tienes implementaciones en otros ecosistemas, como en Go, o incluso OCaml. Y está TenStack Blink, lo siento, TenStack Query, de los mismos creadores de TenStack Query y otros, donde no tienes RSCs per se, pero es un proyecto muy interesante para jugar con la co-localización y la extracción de lo que es cliente, lo que es código del servidor.

Wow. Hemos cubierto realmente rápido un poco de hidratación, reanudabilidad, islas de transmisión, etc. Y siento que podríamos estar aquí todo el día hablando de muchas otras cosas cuando se trata de patrones de representación, pero quiero saltar y hablar un poco sobre lo que creo que viene en camino.

Entonces, sí, tuve que usar un meme. Pero creo que estaremos discutiendo mucho sobre enrutamiento y revisando todo esto de las MPAs y SPAs, y dónde queremos manejar la navegación, y revisando esta decisión de la comunidad de moverse hacia las SPAs que tuvimos hace una década. También estaremos discutiendo mucho sobre la hidratación y nuevas y creativas formas de superar los desafíos de la hidratación. Estaremos discutiendo mucho si queremos tener cero kilobytes de JavaScript o no, y cómo hacerlo. Y creo que estaremos discutiendo mucho la extracción de código. Y como señaló Dan hace un par de años, creo que la próxima ola de tecnologías va a ser sobre coordinar tanto a los clientes como a varios códigos de una manera muy, muy elegante, de la mejor manera posible. ¿Y han visto, por ejemplo, esta cosa del atributo de importación? Es una propuesta de Akmah. Acaba de llegar a TypeScript como un lenguaje. Y con eso puedes hacer, por ejemplo, importar JSON con tipo JSON. Entonces me pregunto si en el futuro, por ejemplo, no podremos hacer cosas como importar componentes con tipo cliente o ambos. Me encantaría ver algo así. Y más que nunca, estaremos hablando de por qué una determinada tecnología es el futuro.

Entonces, algunas reflexiones finales. Como probablemente notaron, cuando encuentran una solución a su problema, probablemente solo están cambiando el problema que tienen. Y mientras muchas de estas soluciones parecen competitivas, creo que la mayoría de ellas son en realidad complementarias. No resuelven el mismo problema al mismo tiempo. En cambio, se centran en diferentes partes del mismo problema. Y es por eso que el mismo patrón puede ser bueno o malo, dependiendo de qué aplicación, qué parte de tu aplicación, etc., qué caso tienes. Es por eso que realmente me gusta esto. Es una publicación llamada Holotipos de Aplicación de Jason Miller, donde básicamente exploró los diferentes tipos de aplicaciones que puedes construir, como una red social, un e-commerce, etc. Y propone, OK, ¿cómo quieres construir la representación para eso? ¿Cómo quieres construir la navegación? Y Ryan Corneado incluso expande un poco más sobre eso, hablando sobre, por ejemplo, ¿cómo quieres hacer la hidratación? ¿Cómo quieres hacer el enrutamiento para cada uno de estos holotipos? Así que realmente me gusta.

Otro meme, y creo que es fácil pensar cuando vemos todos estos ejemplos con el enrutador de la aplicación, por ejemplo, y estas nuevas tecnologías, pensar que solo estamos volviendo a representar HTML en el servidor como lo hacíamos en el pasado. Pero la cosa es que, con PHP y Rails, el límite, básicamente estaban representando ese HTML y tomando presentaciones de formularios, y eso era prácticamente todo. Años después, Marco intentó empujar el límite más allá, pero supongo que la mayoría de nosotros estábamos ocupados construyendo SBAs. Y luego, más recientemente, tuvimos el PHP en la comunidad de Ruby y la comunidad de Elixir iniciativas como LiveWire, HotWire, etc., donde intentaron empujar este límite, pero provenientes de un trasfondo de back end. Creo que quick y los componentes de servidor son un intento interesante proveniente de un trasfondo de front end para empujar este límite mientras se respeta completamente lo que es cliente y lo que son las preocupaciones del servidor. Además, como probablemente notaron, el desarrollo de software siempre está pasando por ciclos.

Y es importante que pensemos que muy probablemente no somos los primeros en intentar algo. Por lo tanto, es importante que pensemos, ¿qué es diferente ahora? ¿Y qué fue una gran idea en el pasado que simplemente se convirtió en un arte perdido? Y tengo dos ejemplos de eso. El primero es este tweet de Andrew, también colaborador principal de React, donde señaló que gran parte de cómo React trabaja con fibras y todo el árbol mecanismo de comparación, etc., se inspira en esta técnica de doble buffering que ha estado en la industria de los videojuegos durante décadas. Y el segundo ejemplo es que cuando Dan publicó que muchas de las cosas interesantes que estaban experimentando con React en 2020 las estaban descubriendo en Marcos en 2014. Y esta publicación del equipo de Marco a la que enlaza enlaza a otra publicación que se publicó en 2005.

Estoy de acuerdo en que todo suena realmente complejo, y creo que debería, porque estamos tratando de abordar un problema complejo que es la variedad de condiciones de red y capacidades de dispositivo de nuestros usuarios. Y si pensamos en el día del diseño responsive, tuvimos un desafío similar. En 2010, tuvimos que enfrentar una cantidad impredecible de tamaños de pantalla, resoluciones de pantalla, etc., así que soluciones complejas para problemas complejos. Eso es lo último.

Así que ya sabes lo que dicen, una imagen vale más que mil palabras. Así que este soy yo hace una década, y estaba en este encuentro de iOS, y estaba muy emocionado con Ionic en aquel entonces. Y les dije, saben qué, dejen de construir esas aplicaciones nativas y empiecen a usar Ionic, porque Angular va a ser el futuro. Y aquí estoy tratando de hablarles del futuro de React a ustedes. Así que sí, no siempre confíen en esas predicciones de futuro y especulaciones y etc., porque el cliché es cierto. No hay una solución mágica. Por eso es importante que ustedes identifiquen sus métricas clave, y no solo cosas como los vitales web y etc., sino métricas de negocio reales, tasas de rebote, tasas de conversión, etc. Esas métricas de rendimiento, son importantes cuando se combinan con sus métricas de negocio reales. Este soy yo. Pueden encontrarme en todas partes como wide accommodator. Soy un ingeniero de front-end en Medallia. Enseño a estudiantes de front-end en Tech Labs, y soy un experto de Google en rendimiento. Los enlaces para esta masterclass y otras masterclass que tengo sobre internos de React, optimización de rendimiento, etc., pueden encontrar aquí. Muchas gracias. Creo que tendremos unos cuatro minutos para preguntas, así que gracias por tenerme. Gracias. Gracias.