Acelerando tu aplicación de React con menos JavaScript

Spanish audio is available in the player settings
Rate this content
Bookmark

¿Demasiado JavaScript te está afectando? Los nuevos frameworks que prometen no JavaScript parecen interesantes, pero tienes una aplicación de React existente para mantener. ¿Y si Qwik React es la respuesta para un inicio más rápido de las aplicaciones y una mejor experiencia de usuario? Qwik React te permite convertir fácilmente tu aplicación de React en una colección de islas, que pueden ser renderizadas en el servidor y hidratadas de forma diferida, y en algunos casos, incluso omitir la hidratación. Y todo esto de manera incremental, sin necesidad de reescribir el código.

32 min
02 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Mishko, el creador de Angular y AngularJS, habla sobre los desafíos del rendimiento de los sitios web y la hidratación de JavaScript. Explica las diferencias entre el renderizado en el lado del cliente y en el lado del servidor, e introduce Quik como una solución para una hidratación eficiente de los componentes. Mishko muestra ejemplos de gestión de estado e intercomunicación utilizando Quik. Destaca los beneficios de rendimiento de usar Quik con React y enfatiza la importancia de reducir el tamaño de JavaScript para obtener un mejor rendimiento. Por último, menciona el uso de QUIC tanto en aplicaciones MPA como SPA para mejorar el rendimiento en el inicio.

Available in English

1. Introducción a Mishko y builder.io

Short description:

Soy Mishko, el creador de Angular y AngularJS. Actualmente trabajo en QUIC y soy el CTO de builder.io, una herramienta visual sin cabeza que te permite construir páginas mediante la instalación de NPM. Creemos en el código abierto y hemos desarrollado PartyTown y Mitosis. Nuestro equipo de código abierto incluye a Adam Bradley, Manuel y Sammy.

¡Guau, ¿sabes qué? Nada me hace más feliz que ver una sala llena. De verdad, gracias a todos. Es increíble. Y tengo que tomar una foto. Así que sonrían. Muy bien.

Sí. Me gusta comenzar mis charlas con un chiste sobre programación, porque soy padre, etc. Así que aquí está el chiste del día. ¿Cómo se miden las funciones? Bueno, se miden en para-metros. OK, bien, bien. Gracias, gracias, gracias.

Hola. Soy Mishko. Hice esta cosa llamada Angular, AngularJS. Y ahora trabajo en QUIC. Y soy el CTO de builder.io. Builder.io es una herramienta visual sin cabeza. Básicamente es un constructor de páginas. Pero lo que lo hace único es que lo haces mediante la instalación de NPM, en lugar de usarlo como un servicio. Y eso significa que puedes ponerlo dentro de tu aplicación. Y puedes registrar tus propios componentes, lo que significa que tu equipo de marketing puede arrastrar y soltar tus propios componentes en tu sitio web. Y eso significa que no tienen que molestarte para hacer cosas en la interfaz de usuario.

Creemos en el código abierto. Hacemos algunas cosas interesantes. Tenemos PartyTown para llevar tus scripts de terceros y moverlos a WebWorkers. Tenemos Mitosis, que te permite escribir código una vez y generar una salida canónica para todos los frameworks que existen. Incluimos todo, desde Angular hasta web components y todas las demás letras intermedias. Y este es nuestro equipo de código abierto. Adam Bradley, quien trabajó en Ionic, Manuel, quien trabajó en Gin, que es un framework de Go, y Sammy, quien trabaja en Mitosis.

2. The Problem with Website Performance

Short description:

La mayoría de los sitios web son lentos y Google ha desarrollado Core Web Vitals para abordar este problema. Sin embargo, la mayoría de los sitios web reales siguen en rojo, lo que indica un rendimiento deficiente. Es crucial mejorar el rendimiento del sitio web, ya que esto afecta directamente las tasas de rebote, las tasas de finalización y la generación de ingresos.

De todos modos, hablemos de lo que veo como el problema. Y el problema que estamos tratando de resolver es que la mayoría de los sitios web son lentos. Y es un problema tan grande que Google realmente se está enfocando en esto, ¿verdad? Google ha desarrollado esta cosa llamada Core Web Vitals. Y si observas Core Web Vitals, encontrarás algo interesante, que la mayoría de los sitios web, los sitios web reales, no me refiero a sitios de prueba de hola mundo donde lo pones y dices, mira, puedo hacer que esto sea eficiente. No, me refiero a sitios web reales. La mayoría de los sitios web reales están en rojo. Y pocos sitios web como Amazon que realmente tienen el dinero y los recursos para abordarlo están en amarillo. Y eso es un poco extraño porque hay muchos datos que muestran que, hey, cuanto mejor sea el rendimiento del sitio web, menos tasa de rebote tendrás, más finalización de compra, etc., más dinero puedes ganar. Entonces claramente hay algo sucediendo donde las personas saben que los sitios web con buen rendimiento son importantes, pero nadie parece poder lograrlo.

3. The Problem with JavaScript and Hydration

Short description:

El problema es JavaScript. La cantidad de JavaScript enviada al navegador ha aumentado a lo largo de los años, abrumando la ejecución de JavaScript de un solo hilo al iniciar. Esto conduce a puntajes de hidratación deficientes. Cuanto más JavaScript envíes, peor será el rendimiento al iniciar. La hidratación es una solución temporal para el renderizado en el lado del servidor.

Entonces, ¿qué crees que es el problema? ¿Es realmente la pregunta? Y creo que el problema es JavaScript. Puede que estés de acuerdo o no. ¿Quién está de acuerdo en que demasiado JavaScript es el problema? Wow, no hay suficientes manos. Está bien, está bien. Supongo que por eso estoy aquí. Estoy tratando de convencerte.

Entonces, la cantidad de JavaScript que enviamos al navegador ha aumentado a lo largo de los años. Y este es un gráfico que muestra cómo simplemente sigue subiendo y subiendo. Y tiene sentido, porque nosotros, como usuarios, esperamos sitios web cada vez más interactivos. Lo que era interactivo y suficientemente bueno el año pasado no es suficiente este año. Solo queremos cada vez más interactividad. Y eso significa que necesitamos enviar más y más JavaScript. Y esto no es escalable, porque JavaScript es de un solo hilo. Y el hilo único se abruma con demasiadas cosas que están sucediendo. Y todo este JavaScript tiene que ejecutarse al iniciar. Y así obtienes puntajes de hidratación muy malos.

Bien, déjame mostrarte este gráfico interesante. Elegí al azar un par de frameworks. Bueno, no tan al azar. Pero de todos modos, los frameworks muestran, a la izquierda, los puntajes promedio que obtienes en Google Core Web Vitals. Y a la derecha, ves la cantidad de JavaScript que se está enviando. Y el punto que quiero hacer aquí es que estos dos gráficos son básicamente inversos entre sí. Cuanto más JavaScript envíes, peor será tu inicio performance. Y cuanto menos JavaScript envíes, mejor será tu inicio performance. Esto no es una idea tan loca. Es bastante obvio, si lo piensas. Si envías más código, tendrás un peor inicio performance. Entonces, ¿por qué tenemos que enviar tanto código? Y la respuesta a eso es que la hidratación es una solución temporal extraña. Porque antes teníamos el renderizado en el lado del servidor, la forma en que funcionaba era que enviábamos HTML, que era una página en blanco. Era literalmente una página en blanco, sin nada en ella.

4. Client-side vs Server-side Rendering

Short description:

JavaScript descarga, ejecuta la aplicación y la renderiza, lo que resulta en una aplicación renderizada en el lado del cliente. AngularJS inició esta tendencia y React la popularizó. La representación previa en el lado del servidor se introdujo para abordar el problema de una carga inicial no interactiva. Se envía el HTML, seguido de la ejecución de la aplicación y su renderizado. Sin embargo, este enfoque resulta en información duplicada que afecta el rendimiento.

Y luego JavaScript se descargaría, y luego ejecutaríamos la aplicación. Y luego la renderizaríamos. Y finalmente, tendrías una aplicación funcional. Y a esto lo llamaríamos aplicaciones renderizadas en el lado del cliente.

Y creo que AngularJS comenzó esta tendencia, y ciertamente React la popularizó aún más. Y aquí es donde puedes interactuar con la aplicación. El problema era esta caja blanca al frente. Y si fueras a construir un sitio web de e-commerce, la caja blanca al frente sería un problema. Si es Gmail, está bien. No te importa esperar un poco.

Y entonces la gente dijo, necesitamos hacer una representación previa en el lado del servidor. Así que enviamos HTML, esta vez más grande. La caja es más grande. Y ahora envías realmente la imagen, o más bien el sitio web que deseas. El problema es que esto parece más rápido, pero no es interactivo. No puedes hacer clic en él. No puedes hacer nada con él. Y luego vuelves a ejecutar el JavaScript. Ejecutas la aplicación y luego la vuelves a renderizar. Por supuesto, ahora no lo llamas volver a renderizar. Lo llamas reconciliación. Tenemos que darle un nombre elegante. Y reutilizas los nodos del DOM si es posible. Pero si no, los recreas de todos modos así que no importa realmente. Y terminas con la misma interfaz de usuario exacta.

Y luego en este punto es cuando puedes hacer clic en él. Y en realidad es más lento, porque el HTML que enviaste era en realidad más grande. Y si lo piensas, lo que está sucediendo es, bueno, estás enviando información duplicada dos veces, ¿verdad? Si buscas una cadena como `hola mundo`, esa cadena se encontrará una vez en el HTML. Y luego nuevamente, en algún lugar dentro del JSX de tu aplicación que se envía como JavaScript. Y así toda esta información duplicada es parte del problema.

5. The Problem with JavaScript Hydration and Quik

Short description:

El JavaScript vuelve a ejecutar todo para encontrar los listeners y adjuntarlos al DOM. La hidratación parcial divide la aplicación en islas, pero la comunicación entre islas se vuelve un desafío. Quik puede hidratar componentes de React y proporcionar intercomunicación sin agregar más JavaScript. Diferentes frameworks tienen enfoques diferentes para la hidratación, desde completo hasta reanudable. React puede adoptar el enfoque de islas con Quik. Reasonability envía HTML y la página se vuelve visible, con anotaciones que indican el código a ejecutar al hacer clic en los botones.

La otra parte del problema es que el JavaScript se vuelve a ejecutar en todo lo que tuviste que hacer antes. ¿Por qué hacemos todo esto? Lo hacemos porque queremos obtener las cajas rojas. Las cajas rojas son los listeners, ¿verdad? Comienzas en la raíz de la aplicación y luego recorres el árbol de componentes de forma recursiva y buscas dónde están las cajas rojas. Esos son tus listeners. Una vez que los encuentras, puedes adjuntarlos al DOM. Es decir, eso es lo que es la hidratación, ¿verdad? La hidratación es un proceso mediante el cual encuentras tus listeners y esos listeners también necesitan el estado de la aplicación y el estado de la aplicación también necesita saber dónde están los límites del componente en caso de que tengamos que volver a renderizar. Pero todo este trabajo tiene que suceder antes de que la aplicación se vuelva interactiva.

Entonces, una cosa que puedes hacer es hacer una hidratación parcial. Es decir, puedes dividir tu aplicación en islas más pequeñas y luego hidratar esas islas de forma independiente, de forma perezosa o tal vez cuando sean visibles o algo así. Esto es esencialmente lo que hacen frameworks como Astro y Fresh, ¿verdad? Afirman tener un rendimiento de inicio increíble porque dicen: sabes qué, la mayor parte de la página que estás viendo es estática. Solo hay un par de partes interactivas, como por ejemplo, el menú o el carrito de compras, etc. La mayoría de ella no es interactiva, pero este enfoque en particular tiene un problema muy importante. Y es que esencialmente lo creas con un montón de aplicaciones aisladas en una página. Y entonces necesitas resolver el problema de la comunicación entre islas. Es decir, ¿cómo se comunican estas islas entre sí, verdad? Si la caja verde a la derecha representa el botón de agregar al carrito de compras, ¿cómo se comunica el botón de agregar al carrito de compras con la caja a la izquierda que representa el carrito de compras? ¿Cómo se dicen mutuamente, hey, estoy agregando un artículo si están en islas separadas? Y normalmente esto se resuelve, bueno, por el framework. El trabajo del framework es proporcionar estado y empujas el estado a tus hijos y al compartir el estado, permites que los diferentes componentes se comuniquen. Pero si haces islas, ¿cómo se supone que debes comunicarte exactamente? Y lo que quieres es algo que cree islas pero al mismo tiempo pueda hacer la comunicación entre ellas. Y así te voy a mostrar una solución particular, que es lo que Quik puede hacer, es que Quik puede hidratar componentes de React y proporcionar la solución de intercomunicación sin agregar más JavaScript a la ecuación. Y así, un pequeño gráfico para mostrarte es que tienes frameworks que tienen una hidratación completa y todos estos frameworks están explorando formas de hacerlo por prioridad o algo así. Y en el otro extremo del espectro, hay frameworks que son completamente reanudables. Quik es el que trabajo, pero hay un framework interno en Google llamado Wiz que impulsa Google Search, Google Photos y esas aplicaciones son increíblemente rápidas. También tienen la filosofía de la razonabilidad y en realidad eBay tiene un framework llamado Marco, que es extremadamente eficiente para estas cosas llamadas Marco versión seis. Y por supuesto, tenemos estos frameworks en el medio, que son Astro y Fresh que están tratando de adoptar el enfoque de islas. Y así quiero mostrarte cómo React también puede adoptar el enfoque de islas con algo como Quik detrás. Así que hablemos de la razonabilidad muy rápidamente y voy a mostrar un par de demos.

Primero que nada, expliqué cómo funciona la hidratación, así que déjame mostrarte qué es lo diferente acerca de la razonabilidad. Envías HTML, es el mismo HTML que antes y la página se vuelve visible. Ahora, lo interesante de esta página en particular es que dentro de la página tienes anotaciones que te dicen qué código se debe ejecutar si haces clic en un botón en particular. Y así, no solo parece más rápido, realmente estás listo para hacer clic.

6. Interacción del Usuario y Descarga de JavaScript

Short description:

El framework descarga JavaScript de forma ansiosa, pero no lo ejecuta hasta que interactúes con la página. Al eliminar duplicados, la cantidad de JavaScript enviada es menor, lo que ahorra tiempo en el inicio de la aplicación. Permíteme mostrarte una demostración de un renderizado básico de un componente de React utilizando Quickify, que hidrata de forma perezosa el componente. La página se renderiza sin JavaScript debido al renderizado en el lado del servidor.

El usuario puede hacer clic en cosas y ese clic será procesado. En este punto, el framework comienza a descargar JavaScript de forma ansiosa. No lo ejecuta, lo cual es una gran diferencia con respecto a la versión anterior. No se ejecuta, solo se descarga ansiosamente lo más pronto posible para que esté listo para ejecutarse si es necesario. Pero nada se ejecuta hasta que interactúes con la página.

En este punto puedes decir, sí, sí, pero estás haciendo trampa. Tu caja de JavaScript es más pequeña. Excluiste un montón de cosas. Sí, eso es porque el clic puede eliminar duplicados. Al eliminar los duplicados, la cantidad de JavaScript que realmente se envía es significativamente menor. Pero por supuesto, no hay ejecución ni reconciliación que esté sucediendo. Todo se vuelve inmediatamente disponible. Y así ahorras una gran cantidad de tiempo para poner en marcha la aplicación.

Permíteme mostrarte un par de demos. Ok, comencemos aquí. La primera demostración que quiero mostrarte es solo un renderizado básico de 'Hola desde React'. Permíteme mostrarte, veamos. Vamos... Tal vez pueda poner las páginas una al lado de la otra. Aquí tenemos. Aquí hay un componente básico de React. Estoy seguro de que lo has visto millones de veces. Nada sorprendente. Lo que puedes hacer es envolverlo dentro de una función Quickify. Y lo que hace la función Quickify es, básicamente, no puede hacer que el componente de React sea reanudable, pero puede hidratarlo de forma perezosa en algún evento. Y en este caso particular, simplemente lo estamos girando y mostrando que puedes usarlo dentro de un Quick. Y el resultado final está aquí. Hasta ahora, nada realmente interesante. Lo que quiero mostrarte es que no hay JavaScript presente. La página se renderiza porque React en el servidor puede hacer renderizado en el lado del servidor.

7. Renderizado en el lado del servidor e Hidratación de Componentes

Short description:

Renderizamos en el lado del servidor el componente sin interactividad ni JavaScript. Necesitamos hidratar el componente antes de usarlo. Al pasar el cursor sobre el componente, se activa la hidratación automática. La comunicación entre islas es esencial para obtener más funcionalidad.

Y así renderizamos en el lado del servidor el componente como parte del resto de la aplicación. Colocamos el componente React en la interfaz de usuario. Pero debido a la falta de interactividad, sin comportamiento, ese componente en particular nunca se hidrata en el cliente. Estoy filtrando los módulos de beat y nodemodules porque estamos ejecutando en DevModes. Así que no cuento estas cosas en particular, pero realmente solo quiero mostrarte que en cuanto al código se refiere, no hay JavaScript presente.

Veamos la siguiente parte, que es probablemente queremos interactividad. Ok, aquí está nuestro contador. Ups. Ok, hagamos un contador simple. Estoy seguro de que has visto un contador en React millones de veces, ¿verdad? Pero básicamente eso es lo que se vería un contador. Ahora, nuevamente, lo envolvemos dentro de Quickify y lo renderizamos. Y aquí está nuestro contador. Y observa, sin JavaScript. Y si hago clic en más uno, nada funciona. Bueno, por supuesto que no funciona. No hemos hidratado React. Y en algún momento, necesitamos hidratarlo antes de poder usarlo. Y la pregunta es, ¿cuál debería ser el evento mediante el cual puedes hidratar el componente? Y el más obvio, sé que dice clic, pero el más obvio es en realidad al pasar el cursor. Lo siento, estaba jugando. Ok. Digamos que nos gustaría hidratarlo al pasar el cursor. Lo mismo exacto, sin JavaScript. Y observa cómo al mover el cursor, la aplicación se hidrata automáticamente. Y puedes ver que el React ha aparecido porque dice herramientas de desarrollo de React, etc. Y lo que puedes ver es que principalmente, algunos de estos, esto es básicamente código de enlace. Sabe cómo llevarlo a eso. De esta manera, puedes tener una isla, pero la isla no es tan interesante, ¿verdad? Claro, puedes tener una isla, pero realmente quieres tener algún tipo de comunicación entre islas. Como mencioné anteriormente, sí, puedes traer un montón de componentes en una página, pero a menos que esas islas individuales puedan comunicarse entre sí, hay cosas muy limitadas que puedes hacer con ellas.

Reconstruyamos este ejemplo nuevamente. Hagamos otro ejemplo, que es este aquí.

8. Gestión del Estado y Ejemplos de Hidratación

Short description:

En este ejemplo, el estado se mueve al componente padre, permitiendo la comunicación entre los componentes de visualización e incremento. Solo se descarga el JavaScript necesario y se demuestra la comunicación entre islas. Otro ejemplo muestra un componente de deslizador envuelto en Quickify y hidratado según reglas especificadas.

Y este ejemplo, y déjame actualizar para que el JavaScript desaparezca. Entonces este ejemplo es básicamente el mismo ejemplo, ¿verdad? Puedo hacer clic en él y ejecutarlo. Y como puedes ver, el JavaScript aparece cuando paso el cursor sobre él. La pregunta es, ¿cómo es esto diferente? Así que echemos un vistazo.

Entonces, bien. La diferencia que voy a hacer aquí es que he construido el contador, pero nota que moví el estado fuera del componente. ¿Verdad, esto es típico de lo que harías, como cuando tienes un componente, digamos un carrito de compras y un botón de agregar al carrito de compras, pones el estado en el padre común, ¿verdad? Y así, en este caso, lo que tengo son dos componentes, visualización e incremento. Y la visualización solo muestra el contador y el incremento solo incrementa, ya sabes, llama al botón de devolución de llamada básicamente, es solo un botón glorificado. Y moví el estado al padre, que en este caso es un componente rápido. Y al pasar el estado, al tener el estado en el padre, ahora puedo pasar el estado tanto a una visualización como puedo pasar un callback al incremento, ¿verdad? Y de esta manera, puedo hacer que el incremento se comunique entre sí. Y lo que quiero mostrarte es que no hay JavaScript presente aquí, ¿verdad? Cuando paso el cursor sobre este botón, ¿verdad, el JavaScript para el botón aparece. Así que en este punto, despertamos el componente e hidratamos solo el botón. Así que déjame borrar esto por un segundo, para que puedas ver. Ahora, si presiono más uno, lo que descargamos fue solo un fragmento de código que era el callback, solo el conteo más más, ¿verdad? Así que descargamos este callback y nada más, ¿verdad? Así que solo se descargó este callback. Pero una vez que modificamos la visualización, ¿verdad? Entonces, una vez que esta señal se modificó, el sistema fue como, oye, esta señal se está pasando a la visualización. Y como resultado, ahora también tenemos que despertar la visualización. Y así, el segundo archivo que se descargó aquí es la visualización, y este es solo el código de React. para la visualización que se hidrata y se vuelve a renderizar, etc. para que el conteo se actualice. Y lo que realmente quiero mostrarte es esta comunicación entre islas. Y creo que esta es la clave, ¿verdad? Sin comunicación entre islas, las islas no son realmente útiles.

Bien, hagamos algo más divertido. Aquí hay un componente de deslizador. Aquí, déjame actualizar la interfaz de usuario nuevamente. Y veamos un deslizador. Deslizador. De acuerdo, lo que hice con el deslizador es que noté que tomé un material UI, como una biblioteca existente que es muy popular en Qwik, React, y lo envolví en un Quickify, y especificé las reglas bajo las cuales debería ser hidratado. Así que simplemente dije, ya sabes, cuando alguien pasa el cursor sobre esta cosa en particular, quiero que lo hidrates. O hay otras reglas. Puedes decir, puedes hacer un evento específico, como desplazamiento, o puedes decir que es visible, o algo así, pero hagamos solo pasar el cursor para nuestros propósitos. Y así, tomando este componente Quickify, puedo colocarlo aquí. Y también puedo tener una entrada regular, que es un componente estándar de HTML.

9. Hidratación e Intercomunicación

Short description:

El código se activa al pasar el cursor sobre el deslizador de Material UI. Arrastrar el deslizador actualiza el otro lado. Solo se descarga el código necesario. El sistema activa el otro componente al arrastrar el componente nativo. Dividir la aplicación en islas mejora la capacidad de respuesta al inicio. La tabla en Material UI se hidrata de manera anticipada cuando entra en vista. React se activa e hidrata el componente. Gracias.

Y luego, por supuesto, el estado está aquí arriba. Y así puedo vincular el estado entre la isla de React y el componente de Qwik aquí. Y lo que quiero mostrarte es que sucede lo correcto.

Así que primero que nada, cuando paso el cursor sobre el deslizador, el deslizador de Material UI, ¿verdad, el código se activa? Observa que si paso el cursor sobre el de HTML, no sucede nada, pero si paso el cursor sobre el de Material, se activa el código. Permíteme borrar esto para que sea más obvio. Y luego, cuando comienzo a arrastrarlo, se actualiza de inmediato el otro lado.

Nuevamente, lo que puedes ver es que el código que descargamos es solo el código para el callback, ¿verdad? Entonces, el único código que descargamos es básicamente este código aquí, donde asignamos el valor porcentual al valor del nuevo deslizador, etc. Y lo contrario también es cierto. Si actualizo, no tengo código. Nada está hidratado, ¿verdad? Y comienzo a arrastrar el componente nativo. El sistema se da cuenta, como, oh, tengo que ir y activar el otro. Y así también se activa el otro componente, y tienes un sistema completamente funcional también.

Y así, nuevamente, lo que puedes obtener es decir, oye, tu aplicación es demasiado grande. Al dividirla en islas, podemos tener una mejor capacidad de respuesta al inicio, pero necesitamos resolver el problema de la intercomunicación. Y finalmente, voy a mostrarte una cosa más, que es una tabla en Material UI. Lo interesante de esta tabla es que todos los componentes que mostré hasta este punto, en realidad se representaron en el lado del servidor, ¿verdad? Pero esta tabla no tiene una capacidad de representación en el lado del servidor. Así que esta tabla se hidrata de manera anticipada. Y así, nuevamente, si me desplazo hacia arriba, si borro la cantidad de JavaScript, cuando la tabla entra en vista, en este punto es cuando React se activa, y se hidrata este componente en particular. Y desde el punto de vista de la interfaz de usuario, ¿dónde está la interfaz de usuario? De acuerdo, aquí está esa tabla. Estoy usando esta tabla en particular, ¿verdad? Esta tabla proviene de la tabla de React, que está aquí. Y esta es una tabla de Material UI, X Data Grid. Y configuras tus datos, etc. Entonces, básicamente, este es tu componente normal de React que harías. Y finalmente envuelves todo el conjunto y le dices al sistema, como, oye, actívalo cuando sea visible. Y sucede lo correcto. ¡Whoa!

De acuerdo, esa es la parte principal de la demostración. No creo que tenga algo más. Solo quería decir gracias.

10. Usando Quik para mejorar el rendimiento de React

Short description:

Estoy feliz de responder cualquier pregunta sobre cómo usar Quik para mejorar el rendimiento de React. Builder.io mismo utiliza Quik para su página de inicio. Hemos notado una mejora significativa en el rendimiento con Quik en comparación con otros frameworks de hidratación. La diferencia en el tiempo de hidratación puede ser de hasta 60 segundos frente a 400 milisegundos en una CPU moderna. Por ejemplo, el sitio Rosa, Bélgica, prioriza enviar la menor cantidad de JavaScript para un mejor rendimiento, incluso en áreas con cobertura de red lenta.

Estoy seguro de que tienes preguntas. Estoy feliz de responderlas. Estoy feliz de responderlas aquí en el escenario o después afuera. Y solo quería mostrarte cómo puedes usar algo como Quik para mejorar el rendimiento de React. Gracias. Gracias. Gracias.

La primera pregunta que tengo personalmente, que hago principalmente cuando escucho sobre estas nuevas tecnologías. ¿Hay algún usuario que ya conozcas que esté usando esto y te sorprenda, tipo, no puedo creer que el producto X esté usando esto?

Ya tenemos algunos usuarios. En primer lugar, Builder.io mismo lo está utilizando. Nuestra página de inicio. Tenemos un sistema visual sin cabeza para construir interfaces de usuario. Y muchas veces la gente venía y nos decía, oye, construí un sitio usando tu tecnología, pero no es tan eficiente. Y nosotros les decíamos, bueno, sí, pero no somos nosotros. Es la tecnología de representación subyacente. Y, por supuesto, eso suena como si estuviéramos echando la culpa. Y por eso era realmente importante para nosotros poder mostrar que nuestra tecnología realmente es eficiente. Y lo bueno de Builder.io es que podemos generar salida a través de mitosis, ya sea a Quik, React, Angular, etc. Y lo que notamos es que no importa qué framework de hidratación elijas. El rendimiento es más o menos el mismo. Pero en el momento en que usas un sistema resumible como Quik, el rendimiento se dispara. Y eso es obvio no solo en ese sentido, sino también cuando vas a las herramientas de rendimiento de Chrome, y ves cuánto JavaScript se ejecuta y comparas el antes y el después, y ves una gran diferencia. Ves una diferencia entre 400 milisegundos de hidratación en una CPU moderna frente a 60 segundos de hidratación, ¿verdad?, es una gran diferencia. Y esa diferencia tiene un impacto. Vemos sitios, por ejemplo, el sitio llamado Rosa, Bélgica, que te permite reservar citas con médicos en Bélgica. Y para ellos era extremadamente importante que incluso en una red lenta, en algún lugar del pueblo, que no tiene la mejor cobertura, puedan reservar algo. Y la forma en que pueden hacerlo es enviando la menor cantidad de JavaScript, ¿verdad? Y por eso las tecnologías que envían la menor cantidad de JavaScript son importantes para el rendimiento inicial. Muy bien. Sí. Recuerdo que en una empresa donde trabajaba, hicimos algunas mejoras de rendimiento sin Quik, fue antes de Quik, y de repente la aplicación se volvió tan rápida que ya no confiábamos en que estuviera funcionando.

QnA

Hidratando Componentes de React y Quickify

Short description:

La distinción entre la descarga ansiosa de código y la ejecución perezosa de código en producción. Utilizar un núcleo de CPU secundario para buscar código ansiosamente es una mejora de rendimiento. El código solo se ejecuta o se carga en la VM cuando haces clic en él. Quickify facilita la adaptación en un proyecto grande. Quick resuelve el problema de comunicación entre islas, lo que facilita la división de tu aplicación. El contexto de React puede funcionar entre las islas de React con Quickify utilizando un contexto Quick.

¿Es este un problema conocido para ti? Esa es una buena historia, sí. Solo tienes que confiar en ello. Voy a pasar a las preguntas de la audiencia. ¿Puedo tener las preguntas de la audiencia aquí?

¿Qué sucede con la hidratación del componente de React al pasar el cursor cuando hay una conexión a Internet lenta o ninguna conexión a Internet en absoluto? Debería haber cubierto eso porque esa es la pregunta número uno que todos hacen. Entonces, lo que mostré es ese modo, y en ese modo, las cosas son perezosas para demostrar lo que está sucediendo bajo el capó. Pero en producción, hay una distinción entre la descarga ansiosa de código y la ejecución perezosa de código. Y sé que suena extraño porque hasta ahora, todos pensaban que eso también era lo mismo, pero en realidad puedes tener un service worker que se descargue de inmediato, busque ansiosamente el JavaScript y lo coloque en la caché del navegador, pero en realidad no lo cargas en el V8 o cualquier otra VM que tengas en tu navegador. Entonces, en realidad no lo cargas allí. Y por eso no te penalizan en Core Web Vitals. Y también tiene sentido porque el service worker se ejecuta en un hilo separado y la mayoría de los dispositivos móviles incluso tienen múltiples núcleos de CPU. Y el hecho de que estés utilizando un núcleo de CPU secundario para buscar ansiosamente tu código es en realidad una mejora de rendimiento. Y luego el código solo se ejecuta o se carga en la VM cuando realmente haces clic en él. Así que siempre que cuando navegues por primera vez a la página, puedas buscar el JavaScript asociado, y como señalé, la cantidad de JavaScript es menor de lo que normalmente buscarías porque muchos de los componentes nunca se renderizarán en el cliente, siempre que eso suceda ansiosamente, ¿verdad?, que es lo que hacen los sistemas normales de todos modos, puedes entrar en un túnel donde pierdes la conectividad y el botón sigue funcionando.

Sí, también parecía muy fácil de adaptar en un proyecto grande. Simplemente puedes decir, oye, este es un componente que me está ralentizando mucho. Y parece que puedes simplemente agregar quick allí y es realmente fácil.

Sí, eso fue lo nuestro- Eso fue lo nuestro... Jaja. Lo siento, lo siento. Eso es parte de la broma. Definitivamente, dedicamos mucho tiempo a Quickify porque queríamos asegurarnos de que fuera una buena experiencia. Y como viste, lo único que tienes que hacer es crear un archivo separado en la parte superior. Olvidé mencionar que hay un pragma JSX para indicarle al compilador que use el react.jsx en lugar de quick.jsx. Así que tienes que hacer eso y envolverlo en el componente Quickify, ¿verdad? Y eso te da un componente rápido que luego puedes usar, como puedes ver, en cualquier otro lugar, ¿verdad? Y un punto importante que realmente quiero destacar es que si bien hay otras tecnologías que hacen la hidratación de islas, creo que la diferencia con Quick es que resuelve el problema de comunicación entre islas, lo que dificulta la división de tu aplicación.

Muy bien, siguiente pregunta de la audiencia. ¿Funciona el contexto de React entre las islas de React con Quickify? Ah, buena pregunta. ¿Funciona el contexto? Más o menos, es una pregunta cualificada. No funciona de inmediato, pero lo que puedes hacer es usar un contexto Quick, y luego cuando hagas el envoltorio Quickify, simplemente puedes obtener el contexto Quick y volver a insertarlo como un contexto dentro de Quick.

Contextos, Pruebas y Bromas

Short description:

Puedes hacer que los contextos funcionen entre las islas. El código Quick funciona sin ninguna transformación, lo que permite la carga perezosa. Las pruebas para el componente React pueden seguir ejecutándose sin actualizaciones. Exporta tanto los componentes de contador como los componentes de contador Quickify. Entretén a la audiencia con bromas mientras buscas preguntas.

Por lo tanto, requiere un poco de código adicional, pero sí, puedes hacer que los contextos funcionen entre las islas. ¿Y la gente puede encontrar ejemplos de eso? Sí, claro, genial.

Siguiente pregunta, no puedo leerla, tengo que levantarme. ¿Cómo maneja Quick la carga de JS grande? Desapareció. ¿Puedes tener componentes de respaldo mientras se carga? No, no desaparezcas, deja de hacer preguntas.

¿Cómo afecta el proceso de hidratación perezosa a las pruebas? ¿Cómo... No creo que deba haber ninguna diferencia en las pruebas. Uno de los requisitos que teníamos al construir Quick era que el código debería ser testeable sin realizar ningún tipo de carga especial para el ejecutor de pruebas. Por lo tanto, el código Quick funciona tal cual sin ningún tipo de transformación. La transformación solo permite la carga perezosa, etc. Por lo tanto, todo esto debería ser testeable, una prueba sencilla o simplemente una prueba o lo que sea que tengas.

Entonces, si tengo mis componentes de contador y los envuelvo con Quickify, ¿no necesito actualizar mis pruebas? No, bueno, depende de si estás probando el que es de React o el envuelto, ¿verdad? Supuestamente tienes una prueba para el que es de React así que simplemente sigues ejecutando la de React. Sí, entonces necesito hacer una nueva exportación de los componentes de contador y una exportación para los componentes de contador Quickify. Correcto. Ah, sí, claro, entendido, entendido, bien. Necesito obtener las preguntas aquí entonces. Lo siento. Deberíamos moderar.

Mientras buscas preguntas, voy a entretener a la audiencia contándoles un chiste. ¿De acuerdo, también está bien? ¿Cómo se rompen las funciones si dejan de llamarse entre sí? Autenticación de dos factores. Ah, entonces me estás preguntando sobre esto, pensé, ¿qué tiene que ver eso? Eso me ralentiza un poco. Bueno, entonces estás diciendo que debería inventar otro chiste? Por supuesto. ¿Por qué no deberías escribir con un lápiz roto? Porque no tiene punta. Oh espera, espera, espera, un momento. ¿Por qué renunció el programador de JavaScript? Porque no le dieron un aumento. Muy bien, estoy dentro. Estoy dentro. Excepto todas las cookies. Gracias, UE.

QUIC y la Distinción entre MPA y SPA

Short description:

QUIC se puede utilizar tanto en aplicaciones renderizadas en el lado del servidor como en el lado del cliente, proporcionando beneficios de rendimiento al iniciar. La distinción entre aplicaciones de varias páginas (MPA) y aplicaciones de una sola página (SPA) se debe principalmente a la hidratación. Sin hidratación, la línea entre MPA y SPA se vuelve borrosa y la distinción es innecesaria cuando se aborda el problema desde una perspectiva diferente.

¿QUIC solo es relevante para aplicaciones renderizadas en el lado del servidor, verdad? No, también se puede utilizar QUIC con aplicaciones renderizadas en el lado del cliente. Por supuesto, el principal beneficio que proporciona QUIC es el rendimiento al iniciar. Por lo tanto, el mejor lugar para usar QUIC sería en aplicaciones de varias páginas o aplicaciones de página de inicio o comercio electrónico, etc. Pero resulta que incluso en aplicaciones renderizadas en el lado del cliente hay un beneficio. Imagina que tienes tu Gmail y de repente tu Gmail se inicia más rápido porque no tienes que descargar todo el Gmail antes de hacer cualquier cosa, ¿verdad? Así que creo que mientras haya esta distinción entre MPA y SPA, creo que esta distinción se debe principalmente al hecho de que tenemos hidratación. Si quitas la hidratación, resulta que la línea entre MPA y SPA se vuelve extremadamente borrosa y realmente no hay mucha diferencia. Así que creo que es una de esas distinciones que nos hemos creado a nosotros mismos y que era innecesaria una vez que cambias tu punto de vista y miras el problema de manera ligeramente diferente. Entonces, si miras tu ejemplo que acabas de mostrar, ¿dirías que está renderizado en el lado del cliente o en el lado del servidor? Definitivamente está renderizado en el lado del servidor para empezar, pero una vez que estás en la página, puedes hacer renderizado en el lado del cliente. Así que si hago la transición de la página A a la página B, tengo que tomar una decisión. Y una forma de hacer la transición es mediante AHRF, en cuyo caso será MPA, ¿verdad? Como hará una recarga completa. O puedes decir en lugar de AHRF, dices LINK con una L mayúscula, y ahora se convierte en una navegación renderizada en el lado del cliente. Así que realmente, la distinción es muy, muy pequeña. Bien, bien. ¿Puedo usar componentes de NPM en Quickify? ¿Solo cualquier componente? Quiero decir, lo mostré con material UI, ¿verdad? Así que material UI era definitivamente un componente instalado desde NPM, y sí, funciona. Si alguien está en una conexión móvil muy lenta de 3G o incluso en edge, y no puede hacer hover debido a la pantalla táctil, ¿cómo funcionará eso? Oh sí, tal vez hover no fue el mejor ejemplo. Hay otros eventos, como por ejemplo, visible es probablemente el evento más apropiado para escuchar. Y especialmente en dispositivos móviles, la pantalla de visibilidad es muy limitada, por lo que sería una buena opción. Así que creo que un mejor ejemplo sería visible. Lo que pasa es que quería mostrar que se retrasa hasta cierto punto. Y así en mis demos, uso hover porque si fuera visible, todo se haría inmediatamente al iniciar. Así que es más una elección para la demostración que usé hover, pero la visibilidad es probablemente mejor en escenarios del mundo real. Sí, hover es más como si creas software y sabes que tus usuarios no están usando una pantalla táctil, entonces puedes usar hover y de lo contrario no. Sí. Sí. Tenemos un tiempo rápido de preguntas. Ja, ja. Ni siquiera me di cuenta. ¿Cuál sería tu enfoque para usar Quick y hacer que la aplicación sea receptiva en dispositivos móviles? Los dispositivos móviles no tienen eventos de hover. Eso es realmente lo que está sucediendo. Sí. ¿Cómo se configura Quick con react? ¿Cómo se configura? Bueno, tenemos una CLI y escribes NPM run quick, add react. Y presionas Enter y esperas unos segundos para que se instale NPM y estás listo para empezar. ¿Pero eso es muy rápido? Oh, ¿te refieres a si? No, estoy haciendo una broma atrevida. De acuerdo. Eso es todo el tiempo que tenemos para preguntas y respuestas. Así que tenemos que pasar al siguiente ponente. Así que todos, por favor, den una cálida bienvenida a Misko. Gracias. Muchas 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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
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
Top Content
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!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

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 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
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 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion