Debate del Panel de React 19

Demos un gran aplauso a la persona que acabas de escuchar, a Ryan. También, desde Shopify, tenemos a Brooks. Aplaudamos a Brooks. También tenemos al maravilloso, al increíble, Evan. Nuestro maravilloso héroe desconocido en el mundo, especialmente de Next, tenemos a Tim. Y por último, pero definitivamente no menos importante, también tenemos a Satya.

Muy bien, ahora hablaré por mí mismo. A veces los perfiles de Twitter de las personas o tal vez lo que he visto de ellos en GitHub, es una cosa y sé sus nombres, pero luego los conozco en persona y descubro lo que realmente hacen y me doy cuenta de que esta persona hace mucho más de lo que me imaginaba. Y así es como me siento acerca de muchos de los ponentes hoy. Permítanme contarles rápidamente un poco sobre lo que algunos de ellos hacen. Así que tenemos a Satya, quien es miembro del equipo central de React y específicamente, lo cual es realmente útil para esta conversación, hizo mucho trabajo en el compilador de React para React 19. Muy emocionado. También tenemos a Tim de Vercel, quien es el co-creador de Next.js. Personalmente quiero agradecerte porque Next.js es el framework que suelo utilizar primero cuando estoy construyendo cosas. También tenemos a Evan, quien es el co-creador de Expo también. Muchas gracias. He escuchado tantas de tus charlas. Hemos estado en el circuito de conferencias bastante tiempo. Así que estoy emocionado por lo que vamos a hablar hoy. Y un gerente de DevRel de Remix. Las pegatinas de Remix son algunas de mis pegatinas favoritas. Así que quiero agradecerte mucho, Brooks. Y no sé si Ryan necesita una tercera presentación, pero todos conocemos a Ryan de Solid.js equilibrando este panel para que podamos tener una gran conversación.

Muy bien. Muchas personas en este escenario son súper fanáticos de React y Ryan. Estoy bromeando. Pero todos estamos aquí y todos estamos muy apasionados y emocionados por algunos de los aspectos más destacados que vienen con React 19. Así que empecemos con algunas de las grandes noticias de cada uno de ustedes. ¿Cuáles son las cosas importantes que tal vez te emocionan o crees que captarán mucha atención de React 19? Empezaré contigo, Satya, y seguiremos en orden. Técnicamente esto no es parte del lanzamiento 19 en sí, pero está desbloqueado con el lanzamiento 19.

Es el compilador de React. Estoy sesgado, pero eso es lo que me emociona. Sí, sé que volveremos y profundizaremos en el compilador de React, especialmente en su historia. Pero eso es un gran titular.

Y tú, Tim? ¿Qué hay de ti? Sí, no estoy seguro si está funcionando. Oh, sí, esto es mejor. Sí, me gustan prácticamente todas las nuevas APIs, pero especialmente las transiciones y el suspense, y cómo funcionan juntas. Y obviamente, los componentes del servidor ahora son estables, así que eso también es bueno. Genial.

Sí, si no están familiarizados con Expo, es un marco universal de React Native, y estoy muy emocionado por los componentes del servidor que llegan a React Native porque permite la recuperación de datos y los patrones de renderizado detallados que hemos llegado a conocer y amar en herramientas como Next.js y Remix, pero de manera universal. Así que en iOS, Android, Web, básicamente en cualquier plataforma, nunca ha habido algo así en el mundo del desarrollo nativo. Así que estoy extremadamente emocionado.

Personalmente, algo que me emociona mucho es que todas las etiquetas de encabezado, como enlaces y metadatos, se elevan automáticamente al encabezado. Creo que es una API de diseño realmente agradable. Permite a Remix, Next y a todos nosotros dejar de hacer eso nosotros mismos, y lo hace de una manera React en lugar de más bifurcación y más formas de hacer lo mismo. Así que realmente aprecio esa API y todo el trabajo que sé que hizo el equipo de Next para que eso suceda, y también el equipo de React. Genial. ¿Y algo que destaque para ti de React 19 que te llame la atención? Sí, quiero decir, ha habido muchas mejoras ergonómicas, pequeñas cosas que simplemente lo hacen más agradable para el desarrollador. Creo que eso es realmente importante para avanzar. Y también es una de las razones por las que estoy emocionado con el compilador de React, porque me gusta la idea de que el código React idiomático sea el más eficiente en rendimiento. Esa división siempre me ha molestado un poco, y creo que el compilador va en esa dirección.

Bueno, siento que esto es una transición perfecta para volver al tema del compilador de React. Cuéntanos un poco sobre la historia, cómo surgió la idea de construir un compilador de React, y luego cómo avanzaste a través del proceso de diseño, iterándolo. Sé que hablaste un poco sobre esto ayer en nuestra conversación privada sobre cómo trabajaste con él dentro de Meta antes de salir y lanzarlo. Sí, hemos pensado en el compilador durante mucho tiempo en el equipo de React.

De hecho, vi un comentario de 2015 hablando sobre un compilador optimizador. Así que esto es algo en lo que el equipo ha estado pensando durante mucho tiempo. Algo que acabamos de pensar. Y lo hemos intentado varias veces en los últimos seis, siete años. Hubo un intento de Dominic Galloway, quien ahora trabaja en Svelte. Lo probamos internamente y aprendimos muchas lecciones de eso. Y luego, hace un par de años, lo intentamos de nuevo, que es ahora el compilador de React. Así que hubo dos iteraciones del compilador de React que acabamos de lanzar recientemente. La primera en realidad no se lanzó, intentamos lanzarla en Meta, pero nos encontramos con algunos problemas, aprendimos muchas lecciones y luego la reescribimos. Pasamos casi un año probándolo en Facebook, viendo cuáles eran los problemas y cómo solucionarlos. Y ahora estamos en un punto en el que estamos felices de compartirlo con la comunidad. Nuestra premisa siempre ha sido hacerlo bien, hacerlo correcto y hacerlo rápido. Así que ahora estamos en ese punto en el que decimos: está bien, es hora de compartirlo con la comunidad, obtener comentarios de la comunidad y luego hacerlo estable.

No, seguro. Y me encanta cómo lo has llevado, lo has terminado de cocinar, lo has dejado hornear antes de sacarlo. Y ustedes aquí, también diría que son parte de esta comunidad, grandes partes, ustedes, diría yo, lideran o de alguna manera influyen en secciones masivas de la comunidad de React. Entonces, ¿cuál ha sido la adopción del compilador de React, o cómo crees que va a cambiar o influir en las cosas en sus caminos individuales? Empezaré, supongo. Una de las cosas que realmente me gusta del compilador de React es que te permite escribir el React que siempre quisiste escribir. Solo usa funciones como funciones. No tienes que pensar en usar callback o use memo, ese tipo de cosas. Y luego deja que el compilador lo optimice por ti. Y ya está demostrando que se pueden hacer más optimizaciones que solo lo que pensarías tú mismo, ¿verdad? Como memorizar llamadas JSX y partes específicas de JSX que nunca cambian y cosas así. Además, cambia el renderizado para que sea de la manera que esperas también. No vuelve a renderizar partes del árbol que no han cambiado. Mientras que si usas React normalmente y estás memorizando todo, hiciste todo bien, aún ves más renderizados de los que deberías ver, al menos en el modelo mental que tienes sobre cómo React renderiza. Así que soluciona cosas como, un ejemplo es que, mostré esto a un colega, y este colega dijo: pero así es como siempre funciona React. Y yo dije, sí, no, en realidad no es la forma en que crees que funciona. Y ahora realmente es la forma en que crees que funciona. Me encanta que cuando tomas algo y lo simplificas, lo que leo o lo que espero que suceda es realmente lo que sucede, lo sé con certeza. ¿Y ustedes, hay algo que destaque para ustedes?

Una cosa que realmente me encanta del diseño de la API de React es que con el tiempo, se ha integrado en el lenguaje y se siente más nativo para el tiempo de ejecución en el que se está ejecutando. En lugar de extender el componente de React, creas una función, en lugar de crear un elemento, tienes JSX. Y con los componentes del servidor, tienes la oportunidad de escribir componentes que se sienten muy ergonómicos, donde estás escribiendo de forma asíncrona y obteniendo datos, y se siente mucho como JavaScript. Pero luego esto creó una especie de asimetría entre el servidor y el cliente, donde en el cliente todavía tienes un montón de hooks para hacer cosas como use memo, y por lo tanto, estás escribiendo componentes que se ven muy diferentes. Y ahora, con el compilador de React, puedes ocultar muchos de esos hooks, lo que hace que sea un poco más simétrico entre el servidor y el cliente, y se siente más nativo para la plataforma, aunque el compilador hace que React se sienta más como su propio lenguaje de programación que antes. Pero creo que eso es genial, porque los hooks, a veces, rompen tu modelo mental, y este enfoque más profundo hace que se sienta muy nativo para lo que estás escribiendo.

Sí, siguiendo con eso, me pregunto si hay un poco de sensación de pérdida, como, oh, aprendí todo este conocimiento sobre cómo usar memo correctamente y cómo memorizar todas mis cosas manualmente. Es similar para mí a todas las bibliotecas de gestión de estado y cosas así. Estaba muy metido en eso. Todavía son muy útiles para muchas cosas, pero usé demasiado la gestión de estado, y una vez que empecé a usar Remix, y solo teníamos un componente de carga muy simple, una especie de modelo de acción, fue bastante fácil hacer mutaciones efímeras y todas estas cosas. Simplemente dejé de preocuparme por el estado, y se sintió un poco como una pérdida, pero al final estaba realmente feliz, y me pregunto si el compilador hará lo mismo. Es como, oh no, pero todo mi conocimiento, y es como, oh, en realidad no necesito ese conocimiento, y es realmente agradable no necesitarlo. Ahora puedo llenar mi cabeza con más conocimientos inútiles. Sí, es interesante que digas eso, porque Satya me habló anoche sobre las memorizaciones hechas a mano y cómo el compilador de React es mucho más eficiente. Sí, con el hook use memo, no puedes llamarlo condicionalmente. Debe estar a nivel de declaración, pero el compilador puede compilar valores dentro de una condición, por lo que es más... Realmente no quiero decir detallado, pero... Cuidadoso. Es más detallado, menos granular que un use memo, y... El otro problema con la memorización manual es que puede ser frágil si no tienes cuidado y olvidas memorizar un valor, eso puede afectar a todos tus componentes y hacer que todo se vuelva a renderizar. Pero con el compilador de React, el compilador se encarga de asegurarse de que cada valor se memorice, por lo que tus componentes son más estables y no se vuelven a renderizar con tanta frecuencia. Sí, en Facebook, por ejemplo, tenemos ingenieros que trabajan en rendimiento y han pasado mucho tiempo pensando en optimizar el código del producto con use memos. Y cuando queríamos lanzar el compilador, pensamos que sería una mejora en la experiencia de desarrollo y que el rendimiento sería el mismo. Pero en realidad vimos un mejor rendimiento, y también vimos que el rendimiento aumentó tanto que llevó a mejoras en el compromiso del producto. Así que definitivamente es mucho más que una memorización manual, al menos en una aplicación de tamaño razonable cuando varias personas trabajan en ella. Veo muchas cabezas asintiendo en el escenario, lo cual siempre es algo bueno de ver. Es emocionante. Es muy emocionante. Lo implementas y tu aplicación se vuelve más eficiente. Sí.

Sí. No se trata tanto de la sensación de pérdida. Es interesante. Creo que tu conocimiento de React sigue siendo muy valioso aquí, pero la diferencia ahora es que lo has retrocedido, ¿verdad? Puedes llegar mucho más lejos antes de tener que preocuparte por eso. Y a veces esa distancia es suficiente para que muchas personas nunca encuentren ciertas categorías de problemas. El modelo no ha cambiado en absoluto, lo cual es algo increíble de esto. Mantienes la idea de que si tus funciones son básicamente puras, todo lo demás sigue. No, seguro.

Muy bien, hablemos de los impactos de React 19. Veamos algunos de los aspectos específicos del framework y elecosistema deframeworks que existen. En primer lugar, hablemos un poco sobre la funcionalidad o cosas de React 19 que se han implementado o traído a losframeworks. Sé que has trabajado mucho en llevar componentes del lado del servidor a React Native. ¿Cómo ha sido eso y cómo ha sido ese proceso? Sí, fantástico. Es muy difícil, pero también muy gratificante. Las cosas que los componentes del servidor permiten en diferentes plataformas son alucinantes. Hablaré de esto más tarde hoy, así que lo recomiendo mucho porque tendré demostraciones y soy un aprendiz visual. Humilde promoción, humilde promoción. Sí, me resulta difícil aprender de texto. La experiencia de llevar componentes del servidor a React Native ha sido... Creo que cuando hablé con Tim ayer, dijo que era algo gratificante porque eldesign de los componentes del servidor está destinado a ser muy universal y está destinado a existir en este mundo centrado en React, y poder simplemente llevar tanto de eso y colocarlo en entornos de ejecución totalmente diferentes y hacer que funcione casi textualmente. Hay muchos cambios que deben hacerse, pero muchas de las ideas principales que no se estaban ejecutando en dispositivos nativos cuando se escribieron originalmente simplemente funcionaron. Lo cual es fantástico. Simplemente funcionó con un pequeño TM al final. Así que sí, fantástico. Tener la transmisión incorporada, casi nunca ves la transmisión incorporada en una aplicación nativa, y luego tener eso simplemente funcionar, transmitiéndose a las vistas nativas, no sé. Simplemente se siente probablemente la magia más grande que he sentido desde que usé por primera vez React y React Native, y quedé asombrado viniendo de un mundo de Objective C y tener las cosas tan rápidas y componibles. Y para el resto de ustedes también, cuando trabajan con la nueva versión de React y todas las características nuevas, ¿hubo algo que destacó como un gran impacto en suframework específicamente, tal vez como los componentes del lado del servidor?

Sí, definitivamente es interesante ver que para Next.js, gran parte fue en realidad mover todas las piezas que tenía Next.js. Así que teníamos getServerSideProps, getStaticProps, getInitialProps, si has estado aquí el tiempo suficiente. Y todos estos desaparecieron, se fueron. Siguen siendo compatibles en el page strider, solo quiero mencionar que no tienes que migrar a App Writer, ese tipo de cosas.

Han desaparecido en el sentido de que ni siquiera tienes que pensarlo, solo tienes componentes que ahora pueden ser asíncronos y esos componentes pueden hacer la recuperación de datos, pueden hacer caché, ese tipo de cosas. Para nosotros, fue como trabajar mucho con el equipo de React para llevar realmente todas las cosas que Next.js hace por defecto y que hemos implementado a lo largo de los años. Podría ser la carga de scripts, por ejemplo, si haces clic en un enlace y vas a otra página, Next.js inyectaría la etiqueta de script, Next.js inyectaría los estilos, Next.js recuperaría tus datos, ese tipo de cosas. Prefetchearía todo eso. Y todas esas APIs ahora son parte de React en sí mismo. Así que en App Writer, pudimos eliminar alrededor de 10 kilobytes de código específico de Next.js en tiempo de ejecución comprimido con gzip porque todo eso se movió a React. Tuvimos que hacer las APIs de DOM de React que te permiten cargar JavaScript adicional. Ahora, la gran diferencia es que ya no tienes que pensar en el tiempo de las cosas. Lo que tenemos que hacer es esperar a que se cargue el JavaScript, ahora podemos realmente renderizar los componentes de React o cosas así. Pero especialmente el CSS es un buen ejemplo de eso. Si escribes todo eso en React en sí mismo, puede encargarse de toda la programación y el tiempo de los renderizados también. Puede integrarse con la suspensión, mostrar el estado de carga, puede integrarse para no renderizar nada hasta que esté presente tu CSS. Es muy importante evitar ese destello de contenido instalado porque de lo contrario comienzas a renderizar los nodos del DOM y verías tu título pero el título es de repente dos veces más grande porque el CSS se cargó después, ese tipo de cosas. Y si React puede encargarse de toda la programación, puede esperar a que se cargue ese CSS antes de comenzar a renderizar algo en tu pantalla. Todavía puede renderizar el DOM virtual pero solo aplicarlo cuando todo esté listo. Así que eso fue realmente genial para nosotros, y mover next head, proporcionando una API en React para hacer lo mismo donde puedes hacer etiquetas de enlace o título o cosas así en cualquier lugar del árbol de React y automáticamente se encargará de la duplicación y la inyección en head y cosas así. Donde puedes usar el verdadero React para renderizar tus etiquetas de head también. Next head era un poco chapucero porque intentamos recorrer el árbol JSX para crear un falso renderizado de React. Es bueno tener un componente de renderizado en next head, por ejemplo, porque no sabemos cómo renderizar componentes porque no estamos usando React y todo eso ahora es parte de React en sí mismo. Ahora podemos simplemente renderizar una etiqueta de título y hacer la recuperación de datos o puede ser un componente que hace la recuperación de datos y todo eso simplemente funciona. Mucho de eso. Y luego obtienes un montón de optimizaciones gratuitas, como la transmisión, la transmisión fuera de orden, mostrar fallbacks y cosas así que desbloquean nuevas características como el pre-renderizado parcial. Siento que siempre es agradable cuando sale algo nuevo que significa que tienes que hacer esto. Lo cual siempre es lo que queremos como desarrolladores, poder construir lo mejor mientras hacemos esto.

Vamos a dar un paso atrás y hablar un poco menos técnico sobre cómo se hace la salchicha. Porque todos ustedes trabajan en este ecosistema, ¿verdad? Han estado teniendo discusiones. Sé que Next.js tiene un equipo de React, Meta tiene un equipo de React. ¿Cómo es trabajar detrás de escena para que las versiones de React salgan de una manera beneficiosa para todos estos frameworks también?

Si has visto la última versión, hay mucha inspiración no solo de Next. Quiero dar un reconocimiento también a Remix. Muchas de las acciones de formulario fueron inspiradas por Remix. Y mucho también fue inspirado por la pila interna de Meta. La forma en que construimos React, al menos en el lado de Meta, es mirando cómo resolver los problemas que enfrentamos al construir Instagram o Facebook.com. Y tratamos de resolver eso. Y así es como pensamos en resolver problemas. Y luego colaboramos profundamente con personas de Remix, Next y Expo. También tenemos reuniones con Expo. No es solo el equipo de Next y el equipo de React. Nos importan mucho todos nuestros frameworks de Meta y también las bibliotecas. Pasé mucho tiempo ayer hablando con Dominic, que trabaja en React Query, hablando sobre los cambios en la obtención de datos. Así que colaboramos con... Tenemos colaboraciones activas con muchos equipos. Y sí, tenemos mucho contexto compartido con el equipo de Next.js porque solían trabajar en Meta en React. Por eso estamos más alineados en las cosas en las que trabajamos. No, seguro. Lo siento. No quise poner eso exclusivamente entre Next y Meta. Lo reformularé. Me refería a toda la comunidad. También es bueno porque sé, como mencionaste cuando estábamos hablando antes, que también estás emocionado por las acciones de formulario. Y cosas así. ¿Qué piensas al respecto? Sí, quiero decir, es mucho de lo que dijo Tim. Nos permite eliminar la API. Ahora mismo, React Router y Remix, tenemos el problema de tener mucha API, y es un problema que asumimos intencionalmente porque gran parte de eso es para rutas de migración. Estamos realmente interesados en tener buenos caminos de migración para llegar a la próxima versión.

No sé cuándo podremos deshacernos de todos nuestros hooks o incluso reescribirlos para usar los fundamentos de React 19 porque necesitamos compatibilidad con versiones anteriores a la 18 durante un tiempo. Pero es emocionante poder comenzar a eliminar cosas, como dije, con las etiquetas meta y los enlaces y todo lo que se eleva. Así que esa es una API completa que probablemente podamos eliminar, lo cual es realmente emocionante.

Además, estoy muy emocionado por la forma en que estamos abordando los Componentes de Servidor de React, no necesariamente porque sean mejores o algo así, sino porque permite una opción que es mucho más opcional, como `oh, quiero probar los Componentes de Servidor de React en esta página` o `quiero probarlo para esta función`. Para mí, en realidad fue un paradigma muy útil porque la forma en que lo estamos haciendo, si no estás familiarizado, es que puedes enviar un Componente de Servidor de React a través de un cargador. Entonces, como data fue un concepto muy útil para mí porque antes no entendía realmente los Componentes de Servidor de React, los veía como `oh, está bien, esto es data y puedo hacer cosas con data`. Antes, mi data era JSON. Y luego, cuando estaba en el cliente, ejecutaba todo este JavaScript del lado del cliente y ejecutaba todo este tipo de cosas. Y ahora puedo simplemente enviarlo como data. Eso es realmente genial. Bien. Bien. De acuerdo. Se nos está acabando el tiempo, pero tenemos algunas preguntas más de las que quiero hablar. Y vamos a dar un paso más y pensar en todo el ecosistema de JavaScript. Tenemos React, pero también tenemos algunas otras bibliotecas de UI. Y voy a incluir a Ryan aquí específicamente. ¿Cómo crees que React y el avance de React, podríamos decir, van a impactar en todo el ecosistema y las bibliotecas de UI en general? Cuando React se mueve, la gente se mueve. Ha habido muchos ejemplos de esto a lo largo del tiempo. Cosas como la transmisión fuera de orden o el almacenamiento local asíncrono. Hubo soluciones que hacían esto durante años y no pudieron obtener soporte en ninguna plataforma. Nadie quería, a nadie le importaba. React lo hace y de repente todos tienen almacenamiento local asíncrono en tres meses. Transmisión fuera de orden en AWS. Estuve esperando durante tres años. Apareció después de React 18 en cuatro meses.

Tiene un impacto profundo cuando ves estas cosas. Y cuando salen las nuevas versiones, siempre estoy emocionado, porque de muchas maneras, creo que las piezas de la trayectoria del futuro son bastante obvias. Llegan. Y a veces los frameworks más pequeños no tienen que preocuparse por tener clientes o personas que los usen cuando hacen esa migración. Así que, sabes, simplemente lanzaré algo público que probablemente probarán internamente durante los próximos dos años. Así que estoy muy emocionado por React 19, ver cosas como suspense y transiciones que salen y que la gente realmente las use. Lanzamos eso en 2019. Y quiero decir, estoy seguro de que ya más personas están usando eso en React de las que hemos tenido en los últimos cinco años. Así que, entender, poder ver el impacto de este tipo de decisiones y, ya sabes, es realmente genial verlo. Y ayuda a influir, ya sabes, si estamos tomando las decisiones correctas. No tengo ilusiones sobre dónde me encuentro en esa parte del rompecabezas. Así que es muy útil ver cosas que llegan a React y que tienen un impacto más amplio para todos.

Genial. Y antes de terminar, voy a hacer algunas preguntas candentes. Las haremos rápidamente. Haré una pregunta. Iremos en orden. Y solo tienes que responder en una oración. Así que la primera pregunta es... Porque hemos hablado de muchas cosas que están de moda, mucha gente está hablando del Compilador de React, de los componentes de servidor. Bien. ¿Cuáles son las partes subestimadas de React 19 que no están recibiendo mucha atención, pero son realmente útiles? Así que nos sentaremos aquí y responderemos en orden. Para mí, es el operador de uso que se lanzó en la versión 19. No mucha gente lo conoce. Creo que es realmente genial. Bien. Estado optimista. Así que usar optimista y cualquier cosa relacionada con eso.

Genial. Me estoy dando cuenta de que es el operador de uso, no el hook de uso. Me preguntaba cómo llamamos a un operador. Sí, quiero decir, tengo que robarte otra vez. Forward ref es tan bueno. Lo usamos mucho en nativo porque hay tantas cosas imperativas... Estoy hablando demasiado. Sí, en la parte inferior, menciona que hay soporte para componentes web. Parece que nadie está hablando mucho de eso, pero está genial. Sí, no sé. Supongo que todo lo que tengo es... En realidad, estoy emocionado por todos ellos, pero el operador de uso y el potencial que tiene de los selectores y los re-renderizados más granulares creo que es un cambio de juego. Puede que no sea obvio al principio, pero creo que con el tiempo, esto va a ser algo grande.

Eso es increíble. Muchas gracias. No tenemos tiempo, pero hay mucho más de lo que me encantaría hablar contigo y estoy seguro de que a mucha gente de la audiencia le encantaría hablar contigo. Así que cuando la gente esté por ahí, te podrán encontrar en la sesión de preguntas y respuestas del orador después. Ryan definitivamente irá allí. Pero demos un gran aplauso a nuestro maravilloso panel. Muchas gracias, gente.