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

Rate this content
Bookmark

¡Nuestro ecosistema puede ser abrumador! Primero, tuvimos el auge de SSR y SSG, y cada uno tenía su propia pila gigantesca de marcos y herramientas. Luego, la hidratación parcial nos permitió hidratar solo algunos de nuestros componentes en el cliente, lo que hemos visto en los Componentes del Servidor de React.


¿Pero qué pasa con las islas? ¿Tienen alguna relación con el Streaming SSR? Además, ¿qué es la reanudabilidad y por qué sigo oyendo hablar de ella? […] Oh, ¿alguien dijo renderizado en el Edge?


Bueno... Hay muchos enfoques por ahí, y todos ellos argumentan que su filosofía es la mejor. En esta sesión, repasaremos estos patrones de arquitectura/renderizado, para ayudar a arrojar algo de luz sobre cómo se implementan algunos y los conceptos detrás de ellos.

26 min
20 Oct, 2023

AI Generated Video Summary

La charla de hoy introduce los conceptos de hidratación y de islas desconectadas, explora los beneficios de las islas para mejorar el HTML renderizado en el servidor con JavaScript en el cliente, discute el enfoque perezoso de la re-zoomabilidad y sus ventajas sobre la hidratación tradicional, destaca el uso de la reanudabilidad y React concurrente para mejorar el rendimiento del renderizado, examina las características y preocupaciones de los componentes del servidor de React, toca la co-ubicación del código del cliente y del servidor, y explora las tendencias futuras en renderizado y navegación. La charla también reflexiona sobre ideas pasadas y enfatiza la importancia de identificar las métricas clave para la optimización del rendimiento.

1. Introducción a la Hidratación y a las Islas Desconectadas

Short description:

Hoy discutiremos la hidratación, sus desafíos y problemas, y el concepto de islas desconectadas introducido por Jason Miller en 2020.

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.

2. Introducción a las Islas y Sus Beneficios

Short description:

Las islas son una forma de mejorar selectivamente el HTML renderizado en el servidor con JavaScript del lado del cliente, proporcionando pequeños fragmentos de interactividad enfocados. Permiten una mayor especificidad en la mejora de la página y pueden ser entregadas e hidratadas de forma independiente. Existen varias herramientas y marcos disponibles para construir islas, como Astro, Quake, Markle, Preact, Solid y Svelte. Markle y Astro ofrecen interesantes combinaciones de características, incluyendo streaming, hidratación parcial automática y estrategias de carga personalizables. Las islas ayudan a reducir el código JavaScript enviado al cliente, resultando en cargas de página más rápidas y mejorando métricas como TTI.

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.

3. Introducción a la Re-zoomabilidad y al Enfoque Perezoso

Short description:

Las islas podrían no ser una buena opción si terminas con muchas islas y pierdes el punto. La re-zoomabilidad permite pausar la ejecución en el servidor y reanudar en los clientes. OPA, Meteor y Quik son ejemplos de lenguajes y marcos que adoptan la reanudabilidad. La hidratación tradicional tiene un enfoque ansioso, mientras que la reanudabilidad adopta un enfoque perezoso. El cliente aprovecha la deserialización para evitar repetir el trabajo.

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.

4. Reanudabilidad y React Concurrente

Short description:

La reanudabilidad mejora el rendimiento de inicio y renderizado al volver a renderizar solo el cambio de componentes. Se recomienda la precarga de interacciones críticas de la página y el aprovechamiento de QUIC. El Streaming-SSR, combinado con la Hidratación Selectiva, permite una interactividad más rápida y prioriza la hidratación para las partes interactuadas por el usuario. Este enfoque concurrente de React elimina la espera de componentes lentos y mejora la transmisión general de la página.

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.

5. Introducción a los Componentes de Servidor de React

Short description:

Los componentes de servidor de React (RSC) se conocían anteriormente como React Flight y se introdujeron a finales de 2020. RSC permite el renderizado anticipado durante el tiempo de construcción en un servidor y está integrado con la obtención de datos y la agrupación. Los RSC son similares a las islas pero no tienen un límite claro entre el servidor y el cliente. El código para los componentes del servidor no se envía al cliente, proporcionando un mejor rendimiento. Los RSC también permiten el acceso al backend desde cualquier lugar dentro del árbol y pueden ser reobtenidos manteniendo el estado del lado del cliente. Sin embargo, quedan preocupaciones sobre los posibles datos a través del cable y la orquestación de los RSC para los constructores de marcos y aplicaciones.

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.

6. Introducción a los Componentes de Servidor y Co-localización

Short description:

Los RSCs traen una interesante discusión sobre la co-localización del código del cliente y del servidor. JacksR, una biblioteca de 2008, tenía similitudes en la coordinación del código del cliente y del servidor. Todavía hay mucho que aprender sobre los componentes del servidor, con transmisiones en vivo y proyectos paralelos como Wacoo y TenStack Query. Estos proyectos exploran la co-localización y la extracción del código del cliente y del servidor.

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.

7. Tendencias Futuras y Holotipos en la Representación

Short description:

Discutiremos sobre enrutamiento, revisaremos las MPAs y SPAs, superaremos los desafíos de la hidratación, lograremos cero kilobytes de JavaScript y la extracción de código. El futuro puede implicar la coordinación del código del cliente y del servidor, como importar componentes con clientes de tipo. Las soluciones en la representación y navegación dependen de los requisitos de la aplicación. La publicación de los Holotipos de Aplicación explora diferentes tipos de aplicaciones y sus enfoques de representación y navegación. La evolución de la representación HTML en el servidor ha progresado desde las presentaciones de formularios básicos hasta empujar los límites con iniciativas como LiveWire, HotWire y componentes de 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.

8. Reflexión sobre Ideas Pasadas y Consideraciones Futuras

Short description:

Es importante considerar qué es diferente ahora y qué ideas del pasado se han convertido en artes perdidas. React se inspira en técnicas como el doble buffering en la industria de los videojuegos y experimentos previos con Marcos. Abordar la complejidad de las condiciones de red y las capacidades del dispositivo es un desafío, similar a los tamaños de pantalla impredecibles que se enfrentan en el diseño responsive. Confiar en las predicciones y especulaciones futuras puede ser engañoso, ya que no existe una solución mágica. Identificar las métricas clave, incluyendo las métricas de negocio, es crucial para la optimización del rendimiento. Soy un ingeniero de front-end en Medallia, un profesor en Tech Labs, y un experto de Google en rendimiento.

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.

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

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn