Acelerando tu aplicación React con menos JavaScript

Vaya, ¿sabes qué? Nada me hace más feliz que ver una sala llena. Como ustedes, realmente, gracias. Esto es increíble. Y tengo que tomar una foto. Así que sonríe. Muy bien.

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

Hola. Soy Mishko. Hice esto llamado Angular, AngularJS. Y ahora trabajo en QUIC. Y soy el CTO de builder.io. Builder.io es una herramienta visual headless. Es básicamente un constructor de páginas. Pero lo que es único en él es que lo haces instalándolo con 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 marketing puede arrastrar y soltar tus propios componentes en tu sitio web. Y eso significa que no tienen que molestarte para hacer cosas para la UI.

Creemos en el código abierto. Hacemos un par de cosas geniales. Hay PartyTown para llevar tus scripts de terceros y moverlos a WebWorkers. Hay 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 componentes web y todas las demás letras en medio. Y este es nuestro equipo de código abierto. Adam Bradley, que trabajó en Ionic, Manuel, que trabajó en Gin, que es un framework de Go, y Sammy que trabaja en Mitosis.

De todos modos, hablemos de lo que veo que es 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 algo llamado Core Web Vitals. Y si miras Core Web Vitals, vas a encontrar algo interesante, que la mayoría de los sitios web, sitios web reales, no me refiero a sitios del tipo hola mundo donde los publicas y dices, mira, yo puedo hacer que esto sea eficiente. No, estoy hablando de sitios web reales. La mayoría de los sitios web reales están realmente en rojo. Y pocos sitios web como Amazon que realmente tienen el dinero y los recursos para ir tras ello están realmente en amarillo. Y eso es algo extraño porque hay muchos datos que muestran que, hey, cuanto mejor es el rendimiento del sitio web, menor es la tasa de rebote, más finalizaciones de compra hay, etc., más dinero puedes ganar. Así que claramente hay algo que está pasando donde la gente sabe que los sitios web basados en la web son importantes, pero nadie parece ser capaz de llegar allí.

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

Entonces, la cantidad de JavaScript que enviamos al navegador simplemente 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 suficientemente bueno este año. Simplemente queremos más y 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 ve abrumado con demasiadas cosas que están sucediendo. Y todo este JavaScript tiene que ejecutarse en el inicio. Y entonces obtienes puntuaciones de hidratación realmente malas.

Bien, déjame mostrarte este gráfico interesante. Elegí al azar un par de frameworks. Bueno, totalmente no al azar. Pero de todos modos, los frameworks muestran, a la izquierda, ves las puntuaciones que obtienes en promedio 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 esencialmente inversos el uno del otro. 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 code, tendrás un peor inicio performance. ¿Y por qué tenemos que enviar tanto code? Y la respuesta a eso es que la hidratación es una solución alternativa extraña. Porque antes teníamos la renderización del lado del servidor, la forma en que esto funciona, enviamos HTML, que es una página en blanco. Era literalmente una página blanca, sin nada en ella.

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 del lado del cliente.

Y creo que AngularJS inició esta tendencia, y ciertamente React la popularizó más. Y este es el punto en el que puedes interactuar con la aplicación. El problema era esta caja blanca al principio. Y si ibas a construir un sitio web de e-commerce, la caja blanca al principio es un problema. Si es un Gmail, está bien. No te importa esperar un rato.

Y entonces la gente dijo, necesitamos hacer pre-renderizado del lado del servidor. Así que enviamos HTML, esta vez más grande. La caja es más grande. Y así ahora realmente envías la imagen, o más bien el sitio web que quieres. El problema es, esto aparece más rápido, pero no es interactivo. No puedes hacer clic en él. No puedes hacer nada con él. Y entonces vuelves a ejecutar el JavaScript. Ejecutas la aplicación, y luego la vuelves a renderizar. Por supuesto, ahora no lo llamas re-renderizado. 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 realmente no importa. Y terminas con la misma UI exacta.

Y entonces 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á pasando 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, de nuevo, en algún lugar dentro del JSX de tu aplicación que se está enviando como JavaScript. Y así toda esta información duplicada es parte del problema.

La otra parte del problema es que el JavaScript está volviendo a ejecutar todo lo que tuvo que hacer antes. ¿Por qué hacemos todo esto? Bueno, lo hacemos porque queremos obtener las cajas rojas. Las cajas rojas son los oyentes, ¿verdad? Así que empiezas en la raíz de la aplicación y luego recorres tu árbol de componentes, ¿verdad? Y vas recursivamente a través de todos los componentes y buscas dónde están las cajas rojas. Esos son tus oyentes. Y una vez que los encuentras, puedes adjuntarlos al dom. Quiero decir, eso es lo que es la hidratación, ¿verdad? La hidratación es un proceso por el cual encuentras tus oyentes y esos oyentes también necesitan tu 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.

Y entonces una cosa que puedes hacer es que puedes 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, perezosamente, o quizás en una visibilidad o algo así. Y esto es esencialmente lo que los frameworks como Astro hacen y también Fresh, ¿verdad? Ellos reclaman un increíble rendimiento de inicio porque dicen, ¿sabes qué? La mayor parte de la página que estás viendo es estática. Realmente sólo hay un par de bits interactivos como por ejemplo, el menú o el carrito de compras, etc. La mayor parte de ella no es interactiva, pero este enfoque particular tiene un problema muy importante. Y eso es, que esencialmente creas un montón de aplicaciones aisladas en una página. Y entonces necesitas resolver el problema de comunicación entre islas. Es decir, ¿cómo hablan estas islas entre sí, verdad? Si la caja verde a la derecha representa el botón de añadir al carrito de compras, ¿cómo habla el botón de añadir al carrito de compras con la caja de la izquierda que representa el carrito de compras? ¿Cómo se dicen el uno al otro como, hey, estoy añadiendo un artículo si están en las islas separadas. Y normalmente esto se resuelve por, bueno, el framework. El trabajo del framework es proporcionar estado y empujas el estado a tus hijos y compartiendo el estado, permites que diferentes componentes se comuniquen. Pero si haces islas, ¿cómo se supone que debes comunicarte? Y entonces lo que quieres, es que quieres algo que cree islas pero al mismo tiempo puede hacer la comunicación entre ellas. Y entonces voy a mostrarles una solución particular, que es lo que Quik puede hacer, es que Quik puede hidratar los componentes de React y proporcionar la solución de intercomunicación sin traer más JavaScript a la mesa. Y entonces un pequeño gráfico para mostrarles es que tienes frameworks que son de hidratación completa y todos estos frameworks están explorando formas de hacerlo por prioridad o algo así. Y en realidad en el otro extremo del espectro, hay frameworks que son completamente reanudables. Quik es el que yo trabajo, pero hay un framework interno en Google llamado Wiz que alimenta Google Search, Google Photos y esas aplicaciones son increíblemente rápidas. También tienen la filosofía de la razonabilidad y eBay tiene un framework llamado Marco, que es extremadamente eficiente para estas cosas llamado Marco versión seis. Y por supuesto tenemos estos frameworks en el medio, que son Astro y Fresh que están tratando de tomar el enfoque de la isla. Y entonces quiero mostrarles cómo React también puede convertirse en el enfoque de la isla con algo como Quik detrás de él. Así que hablemos de la razonabilidad muy rápidamente y voy a mostrar un par de demos.

Así que primero, expliqué cómo funciona la hidratación y entonces déjame mostrarte qué es diferente acerca de la razonabilidad. Así que envías HTML por encima, es el mismo HTML que antes y la página se vuelve visible. Ahora lo interesante de esta página particular es que dentro de la página, tienes anotaciones que te dicen qué código debería ser ejecutado si haces clic en un botón particular. Y así que no sólo aparece más rápido, estás listo para hacer clic.

El usuario puede seguir adelante y hacer clic en cosas y ese clic será procesado. Y así en este punto, el framework comienza ansiosamente a descargar JavaScript. No lo ejecuta lo cual es una gran diferencia entre el anterior y el actual. No se ejecuta, simplemente se descarga ansiosamente lo más pronto posible para que esté listo para la ejecución si es necesario. Pero nada se ejecuta hasta que interactúas con la página.

Ahora en este punto puedes decir, sí, sí, pero estás haciendo trampa. Tu caja de JavaScript es más pequeña. Como hey, excluiste un montón de cosas. Sí, eso es porque click puede eliminar duplicados. Y así al eliminar los duplicados, la cantidad de JavaScript que realmente se envía es significativamente menor. Pero por supuesto, no hay ejecución o parte de reconciliación que esté ocurriendo. Todo el asunto se vuelve inmediatamente disponible. Y así ahorras una gran cantidad de tiempo en poner en marcha la aplicación.

Así que permíteme mostrarte un par de demos. Bueno, comencemos por aquí. La primera demostración que quiero mostrarte es simplemente un renderizado básico de, hola desde React. Así que permíteme mostrarte, veamos. Vamos... Quizás puedo poner las páginas una al lado de la otra. Aquí vamos. Así que aquí está un componente básico de React. Estoy seguro de que lo has visto millones de veces. Nada sorprendente. Lo que puedes hacer es que puedes 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 perezosamente en algún evento. Y en este caso particular, simplemente lo estamos convirtiendo y estoy mostrando que puedes usarlo dentro de un Quick. Y el resultado final está aquí mismo. Ahora, hasta ahora nada realmente interesante. Lo que sí quiero mostrarte es que no hay JavaScript presente. Así que la página se renderizó, porque React en un servidor puede hacer renderizado del lado del servidor.

Y así renderizamos del lado del servidor el componente como parte del resto de la aplicación. Colocamos el componente de React en la UI. Pero como no hay interactividad, no hay comportamiento, ese componente en particular nunca se hidrata en el cliente. Estoy filtrando los módulos de beat y node porque estamos ejecutando dentro de los DevModes. Así que no cuento estas cosas en particular, pero realmente solo quiero mostrarte que en lo que respecta al code, no hay JavaScript presente.

Entonces, veamos la siguiente parte, que es probablemente queremos interactividad. Vale, ahí está nuestro contador. Vaya. Bueno, hagamos un contador simple. Estoy seguro de que has visto un contador en React hecho millones de veces, ¿verdad? Pero básicamente eso es lo que se vería un contador. Ahora, de nuevo, lo envolvemos dentro de Quickify y lo renderizamos. Y aquí está nuestro contador. Y nota que no hay JavaScript. Y si hago clic en más uno, no funciona. Bueno, claro que no funciona. No hidratamos React. Y así, en algún momento, necesitamos hidratarlo antes de poder usarlo. Y entonces la pregunta se convierte en, ¿cuál debería ser el evento por 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. Vale. Entonces digamos que nos gustaría hidratarlo al pasar el cursor. Exactamente lo mismo, no hay JavaScript. Y nota que a medida que muevo el cursor, la aplicación se hidrata automáticamente. Y puedes ver que 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 code de pegamento. Sabe cómo llevarlo a él. De esta manera, puedes tener una isla, pero una 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é antes, sí, puedes traer un montón de componentes en una página, pero a menos que esas islas individuales puedan hablar entre sí, hay cosas muy limitadas que puedes hacer con ello.

Entonces, reconstruyamos este ejemplo de nuevo. Hagamos otro ejemplo, que es este justo aquí.

Y este ejemplo, déjame refrescar para que el JavaScript desaparezca. Entonces, este ejemplo es esencialmente el mismo, ¿verdad? Puedo hacer clic en él y correr. Y como puedes ver, el JavaScript aparece cuando paso el cursor sobre él. La pregunta es, ¿en qué se diferencia? Así que vamos a ver.

Entonces, vale. La diferencia que voy a hacer aquí es que he construido el contador, pero observa que he movido el estado fuera del componente. Correcto, esto es típico de lo que harías, como cuando tienes un componente que, digamos un carrito de compras y un carrito de compras y un botón de añadir al carrito de compras, pones el estado en el padre común más bajo, ¿verdad? Y así, en este caso, lo que tengo es que tengo dos componentes, visualización e incrementador. Y la visualización solo muestra el recuento y el incrementador solo incrementa, ya sabes, llama al botón de devolución de llamada básicamente, es solo un botón glorificado. Y muevo el estado al padre, que resulta ser un componente rápido. Y al pasar el estado a, al tener el estado en el padre, ahora puedo pasar el estado tanto a una visualización como puedo pasar una devolución de llamada al incrementador, ¿verdad? Y de esta manera, puedo hacer que el incrementador hable entre sí. Y lo que quiero mostrarte es que no hay JavaScript presente aquí, ¿verdad? Cuando paso el cursor sobre este botón, el JavaScript para el botón aparece. Entonces, 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 le doy a más uno, lo que descargamos fue solo un pedazo de code que era la devolución de llamada, solo el recuento más más, ¿verdad? Así que descargamos esta devolución de llamada y nada más, ¿verdad? Así que solo se descargó esta devolución de llamada. Pero una vez que modificamos la visualización, 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 esto es solo el code de React para la visualización que se hidrata y se vuelve a renderizar, etc. para que el recuento se actualice. Y lo que realmente quiero mostrarte es esta comunicación entre islas. Y creo que esto es la clave, ¿verdad? Sin comunicación entre islas, las islas realmente no son tan útiles.

Vale, hagamos algo más divertido. Aquí hay un componente de deslizador. Aquí, déjame refrescar la UI de nuevo. Y entonces, veamos un deslizador. Deslizador. Bueno, lo que hice con el deslizador es que noté que simplemente tomé un material UI, como una biblioteca existente que es súper 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 estoy desplazándome, o puedes decir que estoy visible, o algo así, pero vamos a hacer hover para nuestros propósitos. Y así, tomando este componente Quickify, puedo soltarlo aquí. Y también puedo tener una entrada regular, que es un componente estándar de HTML.

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

Entonces, en primer lugar, cuando paso el cursor sobre el deslizador, el deslizador de Material UI, el código se despierta. Observa que si paso el cursor sobre el HTML, no pasa nada, pero si paso el cursor sobre el material, despierta el código. Permíteme borrar esto para que sea más obvio. Y luego, cuando empiezo a arrastrarlo, inmediatamente va y actualiza el otro lado.

De nuevo, lo que puedes ver es que el código que descargamos es solo el código para la devolución de llamada, ¿verdad? Así que el único código que descargamos es básicamente este código aquí, donde estamos asignando el valor porcentual al valor del nuevo deslizador, etc. Y lo contrario también es cierto. Si refresco, no tengo código. Nada está hidratado, ¿verdad? Y empiezo a arrastrar el componente nativo. El sistema se da cuenta, como, oh, tengo que despertar al otro. Y entonces despierta al otro componente también, y entonces tienes un sistema completamente funcional también.

Y entonces, de nuevo, lo que puedes ganar es decir como, 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 luego, finalmente, voy a mostrarte una cosa más, que es una tabla en Material UI. Lo que encuentro interesante de esta tabla es que todos los componentes que mostré hasta este punto, se renderizaron en el lado del servidor, ¿verdad? Pero esta tabla no tiene una capacidad de renderizado en el lado del servidor. Así que esta tabla tiene que hidratarse ansiosamente. Y entonces, de nuevo, si desplazo hacia arriba, si borro la cantidad de JavaScript, cuando la tabla entra en vista, es en este punto que React se despierta, y se hidrata este componente en particular. Y desde un punto de vista de UI, ¿dónde está la UI? Bueno, aquí está esa tabla. Estoy usando esta tabla en particular, ¿verdad? Esta tabla viene de la tabla React, que es de aquí. Y esto es, de nuevo, una tabla de Material UI, X Data Grid. Y configuras tus datos, etc. Así que este es básicamente tu componente normal de React que harías. Y luego envuelves todo el asunto y le dices al sistema, como, oye, despiértame cuando me haga visible. Y sucede lo correcto. Whoa.

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

Estoy seguro de que tienen preguntas. Estoy feliz de responderlas. Estoy feliz de responderlas aquí en el escenario o después afuera. Y solo quería mostrarles cómo pueden usar algo como Quick para hacer que React sea más performance. Gracias. Gracias. Gracias.

La primera pregunta que tengo personalmente, que hago principalmente cuando escucho acerca de estas nuevas tecnologías. ¿Hay algún usuario ya que conozcas que estés como, vaya, no puedo creer que el producto X esté usando esto?

Así que ya tenemos un par de usuarios. En primer lugar, Builder.io lo está utilizando. Nuestra página de inicio. Tenemos un sistema visual headless para construir interfaces de usuario. Y muchas veces la gente vino a nosotros y dijo, oye, construí un sitio usando tu tecnología, no es tan eficiente. Y diríamos como, bueno, sí, pero no somos nosotros. Es la tecnología de renderizado subyacente. Y por supuesto que suena como si estuvieras pasando la culpa. Y por eso fue realmente importante para nosotros poder mostrar nuestra tecnología siendo realmente eficiente. Y lo bueno de builder es que podemos generar salida a través de mitosis, ya sea a quick, react, angular view, etc. Y lo que notamos es que no importa qué marco de hidratación elijas. El performance es aproximadamente el mismo. Pero en el momento en que vas a un sistema reanudable como quick, el performance simplemente se dispara. Y es obvio no solo en ese sentido, sino también cuando vas a las herramientas de performance de Chrome, y simplemente 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 la CPU moderna versus como 60 segundos de hidratación, 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 para médicos en Bélgica. Y para ellos fue 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 hacer eso es enviando la menor cantidad de JavaScript, ¿verdad? Y entonces las tecnologías que envían la menor cantidad de JavaScript son importantes para el rendimiento de inicio. Muy bien. Sí. Recuerdo en una empresa donde trabajaba, hicimos algunas mejoras de performance sin Qwik, fue antes de Qwik, y de repente la aplicación se volvió tan rápida que no confiábamos en que estuviera funcionando.

¿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 del público. ¿Puedo obtener las preguntas del público aquí?

¿Qué sucede con la hidratación del componente React al pasar el ratón por encima cuando hay una conexión a Internet lenta o no hay conexión a Internet en absoluto? Debería haber cubierto eso porque esa es la pregunta número uno que todo el mundo hace. Así que lo que mostré es ese modo, y en ese modo, las cosas son perezosas para demostrar lo que está pasando bajo el capó. Pero en producción, hay una distinción entre la descarga ansiosa de code y la ejecución perezosa de code. Y sé que suena extraño porque hasta ahora, todo el mundo pensaba en eso como la misma cosa, pero puedes tener un trabajador de servicio que descargue inmediatamente, comienza ansiosamente a buscar el JavaScript y lo coloca en la caché del navegador, pero no lo cargas realmente en el V8 o en la VM que tengas en tu navegador. Así que no lo cargas realmente allí. Y por lo tanto no te penalizan por esto en Core Web Vitals. Y también tiene sentido porque el trabajador de servicio se ejecuta en un hilo separado y la mayoría de los dispositivos móviles incluso tienen varios núcleos de CPU. Y por lo tanto, el hecho de que estés utilizando un núcleo de CPU secundario para buscar ansiosamente tu code es en realidad una buena mejora de performance. Y luego el code solo se ejecuta o se carga en la VM cuando realmente haces clic en él. Así que siempre que cuando navegas por primera vez a la página, puedes buscar el JavaScript asociado, y como señalé, la caja de JavaScript es más pequeña de lo que normalmente buscarías porque muchos de los componentes nunca se renderizarán en el cliente, siempre que eso suceda de manera ansiosa, ¿verdad? que lo hace en 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 que era realmente fácil adaptar en un proyecto ya grande. Puedes decir, hey, este es un componente que me está ralentizando mucho. Y parece que puedes adaptar quick allí y realmente fácil.

Sí, eso fue nuestro- Eso fue nuestro... Jaja. Lo siento, lo siento. Esa es parte de la broma. Definitivamente, pasamos mucho tiempo en Quickify porque queríamos asegurarnos de que es una buena experiencia. Y como viste, realmente lo único que tienes que hacer es crear un archivo separado en la parte superior. Olvidé mencionar que hay un pragma JSX para decirle 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 quick que luego puedes usar, como puedes decir, como puedes ver en cualquier otro lugar, ¿verdad? Y un gran punto que realmente quiero hacer es que mientras que 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, que sin él, hace difícil dividir tu aplicación.

Muy bien, siguiente pregunta del público. ¿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 calificada. Así que no funciona de inmediato, pero lo que puedes hacer es que puedes usar un contexto Quick, y luego cuando haces el envoltorio Quickify, puedes simplemente agarrar el contexto Quick y reinsertarlo como un contexto dentro del Quick.

Entonces requiere un poco de pegamento extra code, pero sí, puedes hacer que los contextos funcionen entre las islas. ¿Y la gente puede encontrar ejemplos de eso? Sí. Muy bien.

Siguiente pregunta, no puedo leerla, necesito levantarme. ¿Cómo maneja Quick la carga de JS grande? Desapareció en mí. ¿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 testing? ¿Cómo hace el... No creo que deba haber ninguna diferencia en testing. Uno de los requisitos que estábamos construyendo Quick era que el code debía ser probable sin hacer ningún tipo de cargador especial para el corredor de pruebas. Así que el código Quick funciona tal cual sin ningún tipo de transformación. La transformación realmente solo te permite hacer carga perezosa, etc. Así que todo esto debería ser probable, una prueba de ritmo sencillo o simplemente prueba o lo que sea que tengas.

Entonces, si tengo mis componentes de contador y lo envuelvo con Quickify, ¿No necesito actualizar mis pruebas? No, bueno, depende de si estás testing el de React o el envuelto, ¿verdad? Así que supongo que tienes una prueba para el de React así que simplemente continúas ejecutando el 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í, está bien, entendido, entendido, bien. Necesito conseguir las preguntas aquí entonces. Lo siento. Deberíamos moderar.

Mientras buscas preguntas, voy a entretener a la audiencia contándoles una broma. ¿Está bien? ¿Cómo se rompen las funciones si dejan de llamarse entre sí? Autenticación de dos factores. Ah, así que me estás preguntando sobre esto, me preguntaba, ¿qué tiene que ver eso con algo? Eso me ralentiza un poco. Entonces, ¿estás diciendo que debería inventar otra broma? Por supuesto. Por qué no deberías escribir con un lápiz roto porque no tiene sentido. Oh espera, espera, espera, un momento. ¿Por qué renunció el programador de JavaScript? Porque no obtuvo un aumento. Muy bien, estoy dentro. Estoy dentro. Excepto todas las cookies. Gracias, UE.

QUIC es relevante solo para aplicaciones renderizadas en el servidor, ¿verdad? No, puedes usar QUIC también con aplicaciones renderizadas en el cliente. Por supuesto, el principal beneficio que proporciona QUIC es el rendimiento de inicio. Entonces, el mejor lugar para usar QUIC sería en aplicaciones de múltiples páginas o aplicaciones de página de inicio o e-commerce, etc. Pero resulta que incluso en aplicaciones renderizadas en el cliente hay un beneficio. Imagina que tendrías tu Gmail y de repente tu Gmail se inicia más rápido porque no tienes que descargar todo Gmail antes de hacer algo, ¿verdad? Entonces, creo que mientras existe esta distinción entre MPA y SPA, creo que esta distinción es causada principalmente por el 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. Entonces, creo que es una de esas distinciones que nosotros mismos creamos que era innecesaria una vez que cambias tu punto de vista y miras el problema de una manera ligeramente diferente. Entonces, si miras tu ejemplo que acabas de mostrar, ¿dirías que está renderizado en el cliente o renderizado en el servidor? Definitivamente está renderizado en el servidor para empezar, pero una vez que estás en la página, puedes hacer renderizado en el cliente. Entonces, si hago la transición de la página A a la página B, tengo una decisión que tomar. Y una forma de hacer la transición es hacer AHRF, en cuyo caso será MPA, ¿verdad? Como que va a hacer 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 cliente. Entonces, realmente, la distinción es muy, muy pequeña. Genial, genial. ¿Puedo usar componentes de NPM en Quickify? ¿Cualquier componente? Quiero decir, lo mostré con material UI, ¿verdad? Así que material UI definitivamente fue un componente instalado en NPM, y sí, funciona. Si alguien tiene una conexión móvil 3G muy lenta o incluso una conexión móvil edge, y no pueden pasar el cursor sobre la pantalla porque es táctil, ¿cómo funcionará eso? Oh sí, quizás pasar el cursor 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 visible es muy limitada, y sería una buena manera. Entonces, 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 demostraciones, uso pasar el cursor porque si fuera visible, todo se haría inmediatamente al inicio. Así que es más una elección para la demostración que usé pasar el cursor, pero la visibilidad es probablemente algo mejor en escenarios del mundo real. Sí, pasar el cursor es más como si creas software y sabes que tus usuarios no usan ninguna pantalla táctil, entonces tienes permiso para usar pasar el cursor y de lo contrario no. Sí. Sí. Tenemos un tiempo rápido para preguntas. Ja, ja. Ni siquiera me di cuenta. ¿Cuál sería tu enfoque para usar quick y hacer que la aplicación sea responsive en móviles? Los dispositivos móviles no tienen eventos de pasar el cursor. Eso es realmente lo que está pasando. Sí. ¿Cómo es la configuración para quick react? ¿Cómo se configura? Bueno, tenemos una CLI y escribes NPM run quick, add react. Y presionas Enter y esperas un par de segundos para que NPM se instale y estás listo para comenzar. ¿Pero eso es muy rápido? Oh, ¿quieres decir que si tú? No, estoy haciendo una broma atrevida. Está bien. Eso es todo el tiempo que tenemos para preguntas y respuestas. Así que necesitamos pasar al siguiente orador. Así que todos por favor den una cálida bienvenida a Misko. Gracias. Muchas gracias. Gracias.