React 19: Innovations and Insights

Hola a todos. Vamos a realizar unas discusiones de panel sobre el futuro de React. Habrá algunas preguntas dulces y algunas preguntas picantes.

Así que comencemos con esta pregunta dulce, que es por favor preséntate. Comenzaré yo. Hola a todos. Mi nombre es Shruti Kapoor. Soy ingeniera de software en Slack. Uso React todo el tiempo. Y estoy súper emocionada por esta discusión de panel porque vamos a hablar sobre React 19, lo que viene, lo que odiamos y cosas sobre React que desearíamos poder cambiar.

Te paso el micrófono. Soy Eli White. Soy uno de los ingenieros de software en el equipo de React en Meta. Hola. Soy Mofey. Soy ingeniero de software en el equipo de React en Meta. Soy Kent C. Dodds. Y enseño a la gente cómo hacer aplicaciones web de calidad. Hola. Soy Theo. Y enseño a la gente cómo hacer aplicaciones web terribles. Soy Mark. Mi trabajo diario es un depurador de viajes en el tiempo en Replay. Y mi segundo trabajo no remunerado es mantener Redux. Soy Tom. Ayudé a crear React. Y ahora soy el director de producto en Vercel. Genial. Qué panel tan genial.

I love you all.

All right. Así que comencemos con una pregunta picante. React 19 está en la etapa RC. Estamos muy emocionados de saber cuándo estará en la etapa estable. Me estás mirando. Te estoy mirando. React 19 ha sido realmente genial, porque realmente hemos tomado mucho del feedback que hemos recibido de la gente, especialmente en torno a los cambios de suspense, si has visto eso. Realmente quiero dar un reconocimiento a Andrew de Vercel, quien ha trabajado muy incansablemente para asegurarse de que ese error se solucione y abordemos las necesidades de la comunidad, asegurándonos de que React 19 sea bueno para la gente. Ha sido increíblemente complicado hacer ese cambio. Y a medida que lo hemos implementado, creo que esta semana, la gente ha comenzado a compartir comentarios. Dicen, oh, esto es realmente lo que debería haber sido desde el principio. Esto es increíble. Hay un par de errores más en los que estamos trabajando. Y luego esperamos que sea estable.

Tengo un punto rápido sobre esto. Regularmente me sorprende cuántas personas sienten que React se está rompiendo todo el tiempo, porque los retrasos con React 19 son un hermoso ejemplo de lo contrario. Tuvieron un RC. Era oro. Estaba listo para salir. Un subconjunto muy, muy, muy pequeño de aplicaciones que usaban suspense del lado del cliente de una manera muy, muy, muy específica tuvo regresiones de rendimiento. Y en lugar de lanzarlo y decirles que lo manejen, ahora han tomado mucho tiempo para asegurarse de que el código de nadie se rompa o incluso funcione peor de lo que solía como resultado de los cambios. Y personalmente creo que deberíamos tomarnos un segundo para aplaudir al equipo por continuar manteniendo nuestras aplicaciones funcionando durante más de 10 años en estas bases de código. Me encanta eso. Me encanta ese reconocimiento.

De hecho, mencionaste que hay algunos desafíos con los que estás lidiando. Realmente me encantaría saber cuál ha sido el error más común que la gente ha planteado sobre React 19. Esa es una buena pregunta. Mofey, ¿tienes alguna idea aquí? Hemos estado escuchando muchas preguntas sobre el compilador. No sé. Creo que los compiladores son solo opt-in.

Estamos en beta ahora mismo. Esperamos obtener una versión estable. Así que, con suerte, nos encantaría recibir más comentarios sobre el compilador si eso está rompiendo algo para ti.

Genial.

Eso es en realidad una buena transición a mi siguiente pregunta, que va a ser cuéntanos un poco sobre el compilador de React y qué te gustaría que la gente supiera. Alguien que ha estado manteniendo el compilador de React durante los últimos dos años. Sí. Estamos muy emocionados de lanzarlo. Lo lanzamos a principios de este año y recientemente lo lanzamos en beta. Nos encantaría que probaras el compilador de React en tu aplicación o tu biblioteca y nos informes si funciona perfectamente, si encuentras problemas. Tenemos una guía de depuración en línea. Tenemos una guía de adopción. Por favor, pruébalo. Hemos estado usando el compilador de React en Meta para las aplicaciones web más grandes de Meta, Facebook.com, Instagram.com, Threads.net. Está disponible para... Hemos habilitado el compilador en casi todos los componentes y hooks de React en Facebook.com, lo cual es realmente, realmente genial. No necesitábamos hacer mucha depuración personalizada. Lo activamos y en su mayoría simplemente funcionó. Tuvimos un par de rupturas de pruebas de intención que depuramos y pudimos solucionar en un par de horas. Creemos que el compilador de React está realmente listo para el mundo. También creemos que el compilador de React está aquí para quedarse no solo como una característica de memoización automática, sino como una parte central de React. Parte de esto es que creemos que el futuro de la experiencia del desarrollador y las herramientas del desarrollador utilizarán el compilador. Comenzaremos fusionando el ESLint existente para React con el impulsado por el compilador que te dará violaciones más poderosas. También esperamos estar trabajando en un IDE de React impulsado por el compilador. Obtienes más que solo Lint. Obtienes consejos educativos para cosas que los usuarios avanzados podrían querer. Sí. Es realmente emocionante. Sé que a Kent Sendy no le gusta la magia, pero hemos estado haciendo mucha ciencia de datos en Meta alrededor del compilador y el despliegue.

Hemos visto mejoras bastante increíbles en el rendimiento y mejoras en el compromiso para muchos de nuestros productos en Facebook e Instagram, pero también ganancias en la eficiencia del desarrollador. Ha sido realmente increíble para nuestros ingenieros.

Creo que eso es muy emocionante. Tienes razón. No me gusta la magia, así que soy cautelosamente optimista sobre el compilador. Espero que pueda seguir siendo... Entiendo que necesita ser una parte central de React, pero si React puede seguir funcionando sin un compilador, entonces estaré satisfecho. Probablemente usaré el compilador, pero mientras pueda seguir escribiendo en vanilla, entonces siento que eso cambia el diseño o limita tus decisiones de diseño de una manera positiva.

Por eso me importa. También quería decir, ¿acabamos de recibir un nuevo anuncio de editor aquí en la conferencia? Eso es increíble. Muy temprano. Muy experimental. Hombre, esos editores están saliendo como locos. ¿Es un fork de VS Code? Sin comentarios. Creo que estamos pensando más como una extensión, ¿verdad? Sí. Como una extensión de VS Code. Tom, ¿querías agregar algo? En la charla de Kent esta mañana, estaba usando create element directamente sin JSX. Con RSCs. No se necesita compilador con RSCs, las últimas características de React. Así que creo que el equipo está comprometido a asegurarse de que continuará funcionando de la manera que lo hace. Gracias, sí.

¿Probaste un componente de clase, sin embargo? Debería haberlo hecho. Una pregunta que veo que se hace mucho es, ¿cuándo podemos esperar posiblemente una capa de interfaz de compilador que no esté impulsada por Babel? Algo relacionado con Rust, SWC, algo que no requiera agregar el cargador de Babel a Webpack. Sí, estamos trabajando en ese plan para los próximos meses. Estamos planeando comenzar a trabajar en eso. Quería mencionar algo que mencionaste. Cuando agregaste el compilador a Facebook.com, un par de pruebas de extremo a extremo pasaron. Solo quiero decir, probablemente deberías tener algunas pruebas de extremo a extremo en su lugar cuando pongas en el compilador. Porque, sí, las pruebas importan.

Lo siento, Theo. ¿Alguna biblioteca que podamos usar, Kent? Pruebo mi código. Tengo una mano. Puedo hacer clic. Muy bien, sigamos adelante.

Mencionaste sobre el IDE, que de hecho vi ayer. Estaba bastante emocionado al respecto. Pero quiero hacer esta pregunta al resto del grupo, que es, ¿hay alguna característica de React 19 que estés muy emocionado de ver?

Sí. ¿Cuáles? Oh, supongo que iré yo. Porque no uso Next.js, no he estado usando RSCs durante el último año y medio o el tiempo que sea. Así que estoy muy emocionado de que los RSCs sean oficialmente estables y un lanzamiento estable de React. Y, por supuesto, las funciones del servidor y todo lo que eso conlleva. Creo que hay muchos patrones realmente, realmente interesantes que podemos obtener. Lo que realmente me encanta de lo que React está haciendo es que va a consolidar el framework. Así que, uso Remix. Theo usa Next. Creo que en el futuro, nuestro código de producto se verá muy similar. Casi podrías usarlos en cualquiera de los dos frameworks. Y realmente me encanta eso. React nos está reuniendo de nuevo. Gracias. Se lo paso a Theo.

Misma pregunta. Quiero decir, esta es toda mi vida. Puedes ir a mi canal de YouTube, y he hecho un análisis profundo de cada cosa genial sobre todos ellos. Pero, creo que el que he tenido el viaje más largo ha sido con el streaming. Pasar de ver el beneficio antes de entender cómo funcionaba en absoluto, a entenderlo profundamente a desarmarlo, e implementarlo yo mismo, para luego ver la forma final de ahora. Ha sido realmente genial ver cómo hemos pasado por este viaje de cómo transmitimos HTML a través del cable de una manera que permite al usuario tener una buena experiencia. Es genial ver que ese rompecabezas finalmente se resuelve de una manera que no solo beneficia a React, sino que no solo beneficiará a otros frameworks en la web. También beneficiará a otros frameworks y ecosistemas no web.

He estado ayudando a algunos equipos en el mundo de Elixir a hacer que esto funcione en Phoenix y Liveview también. Por eso siempre apuestas por React, porque lo conseguimos primero. De alguna manera todavía. ¿Cuántos años tiene React y todavía somos los primeros en tantas cosas? Es increíble.

Una de mis citas favoritas de Theo es, nadie critica a React mejor que el equipo de React. Solo pensar en esto es bastante genial, porque React ha existido durante tanto tiempo, y ha cambiado tanto, pero tu código de producto aún puede ser tan similar a lo que es. Eso realmente habla de la capacidad de agregar cosas a él y agregar estas capacidades, agregar streaming. Sigue siendo solo React. Es lo que estás acostumbrado a usar. Eso es porque vemos todos los defectos, algunos que no ves, y constantemente estamos trabajando para mejorar eso.

Incluso me tomé la molestia cuando AppRouter y React 18, creo, se lanzaron para tomar el ejemplo más antiguo de un componente que pude encontrar en el blog de React. Tuve que traer el nuevo ayudante de clase, como Polyfill que ustedes hicieron, pero pude hacer que el código de 2013 o 14 funcionara en una nueva aplicación de Next.js de 2024 con un solo paquete que ustedes construyeron para este propósito. Puedes ejecutar código realmente antiguo y código realmente nuevo y no solo tenerlos ambos en el mismo proyecto, sino montándolos entre sí e interoperando entre código que tiene diez años y código que escribiste de la manera en que lo haremos el próximo año, y hacer que todo funcione junto. No hay tecnología que yo conozca que haya mantenido ese nivel de interoperabilidad con diferentes formas generacionales de escribirlo como lo ha hecho React. Los navegadores son increíbles. Pero ninguna de las cosas interrumpe, todas simplemente se rompen. Estás componiendo código de 2013 a 2024. Eso es una locura. Es tan bueno.

Mark, ¿qué piensas? Mi cabeza está en un espacio extraño alrededor de muchas de estas cosas. Sigo profundamente lo que está sucediendo dentro de React a nivel de equipo y a nivel de PR e incluso a nivel de código. He estado pensando en cosas como el renderizado concurrente y cómo eso interactúa con bibliotecas externas como Redux durante años. En el trabajo diario, no paso mucho tiempo construyendo UIs yo mismo. Mi propio uso de React tiende a ser lo básico, obtener algunos datos, renderizar una lista, lo que sea. Así que, aunque entiendo muchos de los mecanismos, todavía no he comprendido completamente algunas de las cosas más nuevas de 18, como las transiciones o el uso de valor diferido. Creo que Brian Vaughan trató de explicármelo media docena de veces y todavía solo lo entiendo a medias. Es el hook más difícil, seguro. Por un lado, a veces parece que React del lado del cliente ya estaba completo. Y así estamos obteniendo algunas cosas como supongo que hay cosas nuevas, pero ¿qué es esto? Pero al mismo tiempo, incluso algunas de las cosas nuevas en 19 alrededor de los formularios. ¿Cuántas veces hemos escrito un hook de estado para rastrear el estado de carga de una solicitud? Demasiadas.

Sí. Así que tener cosas realmente integradas en React para eso es claramente algo que va a ayudar a la comunidad. Sí, creo que tienes razón. Los formularios especialmente han sido tan ignorados durante mucho tiempo. Finalmente es muy agradable ver que reciben el respeto que merecen y el trabajo que ponemos en los formularios ahora va a ser automáticamente hecho por React, así que no tenemos que rastrear todas estas cosas manuales.

Estoy de acuerdo. Tom, ¿algo que quieras añadir? Sí, a lo largo de los años ha habido este patrón del equipo de React diciendo, está bien, no tenemos una opinión sobre esta cosa específica. Dejando que la comunidad explore durante mucho tiempo, se concentre en un conjunto de patrones y soluciones, y luego trayendo esos al framework y codificándolos para que todo lo construido encima pueda ser un poco más simple. Eso es lo que me emociona de React 19. Creo que continúa haciendo eso y lo hizo esta vez con el tema de los formularios. Pero creo que el compromiso con el valor económico asociado con React no es el framework en sí. Es todo lo que hemos construido durante la última década. Así que traer esos patrones al framework y mantenerlo fresco y mantener las cosas avanzando hacia adelante, eso es lo que más me emociona.

Lo escuchaste aquí primero. Taylen va a ser parte de React 20. Estaba pensando que las animaciones serían realmente buenas. ¿Estamos centralizados en una solución de animación? Realmente aprecio ese aspecto de React, que no vamos a tomar una opinión sobre algo hasta que estemos seguros de que esta opinión durará una década o más. Honestamente, esa fue una de las cosas que realmente me atrajo de React, fue el compromiso de dejar que la comunidad simplemente trabaje a través de un montón de diferentes soluciones. Cuando Flux fue presentado en Facebook, simplemente pasamos por tantas iteraciones diferentes. Las guerras de Flux. Sí, las guerras de Flux. Ha habido muchos ejemplos de esto donde React es como, sí, simplemente no estamos seguros de cuál es la dirección correcta. Vamos a dejar que la comunidad innove. Honestamente, creo que esa es una de las razones por las que React lidera en tanto, es porque no solo tienes al equipo de Meta y Vercel trabajando en ello. Tienes a toda la comunidad tratando de resolver estos problemas, y luego iteramos hacia algo que es realmente, realmente bueno. Gracias a todos ustedes por iterar en eso. Sí. Sí. Aplaudan por ustedes mismos. Algo que diré como un forastero es que me sorprendió lo abierto que está el equipo de React a tener estas conversaciones.

Eso no es solo porque soy un YouTuber, tienen que escucharme, aunque eso es cierto. Estamos buscando esta retroalimentación. Eventos aleatorios a los que Eli asiste, simplemente hablará con cualquiera sobre esto. Si has tenido un problema con React, te estás frustrando con el framework, estoy asombrado de lo rápido que una conversación con prácticamente cualquier persona del equipo puede mostrarte cuánto lo entienden y se preocupan. No puedo contar la cantidad de veces que he tenido una conversación donde planteé una preocupación sobre una decisión de diseño o una API que no creía que iba a funcionar, y Sebastian simplemente reconfiguraría mi cerebro en dos oraciones. Estos chicos lo entienden. Han estado pensando en estas cosas durante tanto tiempo. El equipo de React no nos muestra cuál es el plan hasta que han... Como dijo Eli, lo dije antes, han sido sus críticos más duros sobre esto durante años antes. Sí. Hablando de retroalimentación, escuchemos. ¿Cuáles son algunas características de React que sientes que son un poco confusas o no utilizadas o te gustaría verlas eliminadas de las futuras versiones de React? Ignorando la última parte, cada hook que se introdujo en 18 y 19... Una de las cosas que solíamos hacer como equipo central era cada vez que el equipo quería introducir una nueva característica, yo preguntaba, algo en broma, ¿cuáles son las tres características que estás eliminando para agregar esta nueva API? No sabía que trabajabas en Preact. Sí. Lo hice en mi vida pasada. Uno de los buenos ejemplos de esto fue obtener el estado derivado de las props. Recuerdo la reunión, estaba bromeando con el equipo, estaba como, de acuerdo, ¿qué tres APIs estamos eliminando para introducir esta? Resultó que en la enorme base de código de Facebook, eliminamos la mayoría del uso de tres APIs. Era como debería actualizar el componente y el componente recibirá props. Espero que siempre haya una especie de refinamiento que esté ocurriendo mientras introducimos nuevas cosas que reduzcan lo que describo como la barrera de entrada. ¿Cuántas APIs realmente necesitas aprender para comenzar? No tengo ningún detalle específico que señalaría que desearía que eliminaran, pero hay mucho de cosas heredadas que probablemente no necesitamos. Creo que tanto ellos como el equipo del compilador han ayudado, ya sabes, a pagar algunas de esas deudas por nosotros. Absolutamente. Me encantaría no volver a llamar a use memo, use callback. Dejemos que la máquina haga lo que la máquina hace mejor que yo. ¿Alguien más quiere añadir algo? React es perfecto. No. Solo estaba pensando en cuando se eliminó create class, lograste aún permitir que lo usáramos teniendo otro paquete. A medida que las cosas se van moviendo y evolucionamos como comunidad con el tiempo, esta es una de las cosas hermosas de React es que continúa evolucionando. No es estático. Siempre está innovando.

Sí, las cosas antiguas van a desaparecer. Me encantaría poder seguir usando el código de React de 2013, 2017 en lo que sea el futuro, y tengo confianza en que el equipo de React no nos va a abandonar a nosotros ni al resto de la comunidad mientras continuamos innovando y moviéndonos en diferentes direcciones. Así que, aunque puede ser frustrante, como, oh, hombre, sacaron clases. Ahora sacaron hooks. Estoy constantemente reescribiendo código de React. Pero no, no tienes que reescribirlo. Probablemente quieras hacerlo. Hay una motivación para llegar allí. Solo aprecio que el equipo de React se preocupe tanto por esa migración. No son exactamente cosas que eliminaría, pero algunos ejemplos de cosas que he visto que la gente pide que están relacionadas con esto. Algunas personas han dicho que no tenemos componentes de clase en nuestra base de código. ¿Podría de alguna manera tener una versión de React que omita completamente el soporte de componentes de clase? He visto gente decir, como, ¿por qué no puedo hacer tree shake a React y de alguna manera dejar fuera las partes de la funcionalidad central que no estamos usando? Mucha gente ha pedido una publicación adecuada de ESM. Sí, por favor. ¡Por favor! Y todas estas cosas en realidad están relacionadas, porque, como, la lógica central de React está muy entrelazada. Realmente no puedes separar la lógica para actualizar un componente de clase. Está en su propio archivo fuente, pero la versión publicada, está todo junto. Así que no hay una sola respuesta, y no estoy aquí suplicando que esto sea eliminado. Pero estos son los tipos de cosas que la gente piensa que está pidiendo, incluso si no entienden lo que se necesitaría para lograrlo o se dan cuenta de que no necesariamente les está ahorrando. Pero pediré el soporte de ESM. Definitivamente queremos ESM.

Así que también tengo una característica que quiero eliminar. Espero eliminar use memo y use callback. Espero que ya ahora. Mañana. Pero hay otra característica que, como, no sé, solo mirando el código, se siente un poco redundante. Y esa es la matriz de deps para use effect. Así que ahora que tienes un compilador que puede entender, como, oh, ¿qué estás usando dentro de tu effect? Es la misma lógica para entender lo que estás usando dentro de tu código de renderizado normal de React ¿verdad? O como tu código de use callback.

Tal vez podamos simplemente usar ese compilador y no tener que preocuparnos por las dependencias del effect. ¿Así que finalmente habrá un caso de uso para una llamada de use effect que no tenga un segundo argumento? Sí. Porque ahora mismo es solo un arma de doble filo. Le estaba contando a Theo la historia el otro día de dónde vino esa matriz al principio, y fue como un gesto de mano hace muchos años. Fue como, bueno, no te preocupes. Un compilador simplemente hará esto algún día. Sí, lo recuerdo. Y cinco años después... Y aquí estamos en una sala llena de compiladores. Finalmente lo hemos hecho. Y Kent aún podrá escribir la matriz de deps.

Todavía puedo hacerlo. Está bien, sí. Eso es bueno. Creo que esto plantea una pregunta interesante sobre el lado educativo de las cosas. Y esto en realidad se relaciona mucho con lo que he pasado con Redux. Redux se enseñó muy temprano como si estuvieras escribiendo todo este código a mano, spreads de objetos y constantes de tipo de acción y todo. Creamos Redux Toolkit como una capa de abstracción. Estás escribiendo menos código. Está usando emmer para actualizaciones inmutables más fáciles. Está generando los creadores de acciones para ti. Pero aún así, en última instancia, tienes que entender los principios de las actualizaciones inmutables para que te des cuenta, como, puedo mutar dentro de la llamada create slice, pero no fuera.

Hay magia sucediendo allí. Y así comenzamos a entrar en lo mismo en términos del compilador o algo así. Si alguien entra en una base de código dentro de tres, cuatro años que ha sido compilada con React durante mucho tiempo, y ven un use effect sin matriz de deps, podrían no darse cuenta de que el compilador está haciendo mucho trabajo por ti. Así que desde el lado educativo, todavía hay una necesidad de enseñar algunos de los conceptos subyacentes y entender que en esta base de código, hay algo de magia sucediendo que me está ahorrando tiempo y esfuerzo.

No tengo una respuesta inmediata para eso. No sé necesariamente la mejor manera de, digamos, organizar la documentación de React. Para la documentación de Redux, lo que terminé haciendo fue que el tutorial principal enseña Redux toolkit y dice que hay algunos bits de magia que necesitas saber a medida que avanzamos, y luego hay un tutorial de fundamentos separado que enseña los conceptos subyacentes sin abstracciones. Tal vez algo de eso necesite integrarse en la documentación de React. No estoy seguro. Pero es una preocupación.

Parece que estarás bien empleado por un tiempo, Kent. Solo iba a decir. Me encantaría que la documentación de React tuviera eso. Ese es mi modus operandi para cómo enseño React, es despojar todas las herramientas. Por eso estaba usando element y cosas así. Simplemente despojar todas las herramientas. ¿Cuál es el núcleo de esto? Y luego, está bien. Ahora eres un profesional. Agreguemos algo de la magia para que esto funcione eficientemente.

No es exactamente la misma educación de la que estás hablando, pero creo que también pensamos en cómo enseñamos a estas nuevas IAs y LLMs los nuevos patrones? A medida que hacemos cambios, a medida que queremos eliminar useMemo y useCallback, ¿cómo hacemos que los LLMs dejen de sugerir esas cosas? No tengo idea. Pero eso es algo que necesitamos resolver. Creo que tenemos que tomar un trago porque acabamos de decir IA. Lo logramos por mucho tiempo sin hacerlo. Estoy orgulloso de nosotros. Exactamente. De hecho, hablando de... Oh, está bien. Estamos tomando un trago. Sí, lo estamos. Esto es sin alcohol, lo prometo.

Tengo una opinión algo controvertida. En realidad, no quiero que la mayoría de las personas que comienzan con React hoy tengan que aprender useMemo o useCallback. Creo que hay un breve período de transición donde de ahora a lo siguiente, necesitas aprender de aquí a allá. Pero después de eso, espero que hayamos establecido una nueva base que no lo requiera. De hecho, invertiría los documentos. Diría que no lo enseñes por defecto y luego lo reveles progresivamente si alguien se topa con ello. Pero escuché sobre el, si entro en una base de código que depende del comportamiento asociado con las herramientas, podría ser confuso. Pero sí, creo que todo el objetivo es hacer que introduzcamos conceptos para llevarnos del punto A al punto B, pero eventualmente el punto B es el nuevo punto de partida.

Esto es una de las cosas que he visto mucho con React que es realmente interesante, es como un problema de gestión de la comunidad donde React nos permite construir cosas que son tan complejas que puedes tener toda una vida de carrera solo construyendo React y aprendiendo todas estas complejidades y detalles. Y sale una actualización que no elimina esas cosas, pero te permite no necesitarlas tanto y trabajar con más piezas, pero el rompecabezas que construyes con él es mucho más simple. Dicho esto, cuando estás tan acostumbrado a vivir en esa complejidad específica y se añade algo más simplemente se siente como más complejidad y puede ser realmente estresante como persona que ha dedicado su vida a crear materiales, documentación, marcos, bibliotecas, y todas estas cosas alrededor de cómo funciona React hoy, que cuando miramos el React del mañana y es diferente, es difícil mapear el modelo mental.

Algo que he encontrado interesante con los componentes del servidor es que han sido más fáciles para mí de enseñar a los desarrolladores no familiarizados con React que a los desarrolladores con una larga carrera en React, porque cuando ven JSX, asumen que es un componente del cliente que se está re-renderizando todo el tiempo y todas estas cosas, pero si lo tratas simplemente como HTML y no estás tan inmerso en la mentalidad de React, es más fácil aprender estas nuevas formas de usarlo. Y una de las preocupaciones que tengo con el compilador es que las personas que están tan inmersas que saben exactamente dónde y cómo usar sus callbacks y memos van a pensar demasiado en lo que está haciendo el compilador y no solo confiar en que haga lo correcto. React IDE. Sí. Solo quiero decir que ambas opiniones son muy buenas. Espero que estuvieras escuchando. Tuvimos lo mismo con Hooks. Recuerdo que antes de Hooks, pasé la primera mitad de mi masterclass enseñando a las personas cómo funcionan las clases en JavaScript.

Y luego enseñaría... Enséñame. Sí. Gracias. No sé si puedo hacer eso más. Pero sí, luego obtuvimos Hooks, y todos los que habían estado haciendo componentes de clase tuvieron que desaprender todo eso, mientras que las personas nuevas lo aprendieron mucho más rápido. Y sí, tiene mucho sentido. Me involucré cuando Hooks estaban sucediendo, y creo que es una gran parte de por qué me metí en React tan rápido como lo hice, porque no tenía el bagaje de la antigua forma de hacer las cosas. Podía simplemente aprender la nueva. Mi primer momento de esos fue con los componentes del servidor, y no me gustaron inicialmente.

De hecho, tenía una pregunta de seguimiento para ti, que es que has estado enseñando React durante mucho tiempo, y tengo curiosidad, ¿cuáles son algunas cosas con las que has visto que la gente tropieza a lo largo de los años que te gustaría cambiar? Sí, ha sido casi una década ahora. Y ha evolucionado, por supuesto. Solía tener que enseñar clases a las personas, y ahora no tengo que hacerlo. Entonces la pregunta es, ¿qué espero no tener que enseñarles en el futuro? ¿Cuáles son algunas cosas con las que la gente tropieza en React? Tropieza. Y por supuesto, efectos que se ejecutan infinitamente, llamar a setState dentro del callback. Eso no sucede mucho en mi instrucción ahora, pero definitivamente hay algunos lugares, porque React se ha vuelto tan bueno, y Epic React 2.0 es todo React 19, así que no estamos usando useEffect mucho, lo cual es, ¡uf, increíble! Pero sí, la memoización es algo que confunde, useDeferredValue es un... Es un hook que no es para un caso de uso específico. Puede hacer tantas cosas, y por eso es difícil realmente... Tengo ejemplos, y aquí están todos los lugares realmente buenos donde usas esto, pero aún así es un poco difícil de comunicar, y eso, creo, me confunde. Confundí a Ryan Florence en un viaje en auto con useDeferredValue, así que no sé. Hice lo mejor que pude. Pero sí, creo que muchos de los desafíos que la gente está teniendo son transformar su cerebro en la nueva forma en que son las cosas. Las personas que lo están aprendiendo ahora, como dijimos antes, lo están entendiendo mejor. ¡Lo siento!

Entonces, también tengo una pregunta para Kent. Entonces, Kent, dices que no te gusta la idea de la magia, pero ¿qué piensas sobre tener un IDE que podría mostrarte, como, oye, esta es otra forma en que podrías escribir esta característica. Este useMemo, realmente no es necesario, porque ya se está memorizando de la misma manera que quieres que sea, o tal vez incluso mejor. Para mí, ese es un buen tipo de magia. Sí, me gusta mucho eso, porque es instructivo, y creo que todos dependemos de mucha magia. No sé cómo funciona realmente mi computadora.

Sabes, tengo algunas ideas sobre transistores y demás, pero, estamos construyendo sobre abstracciones, y en algún nivel, hay algo de magia de la que dependemos. Está bien. Y creo que el compilador puede ser ese siguiente nivel, y luego todos estaremos operando en este nivel utópico. Y cuando realmente quieres entender mejor las cosas, bajas para subir, y ese es uno de los principios épicos de programación de los que voy a hablar.

Pero, sí, estoy cautelosamente optimista sobre el compilador. Creo que habrá un período de transición en el que solo estamos tratando de averiguar, bien, ¿dónde está ese nivel de magia ahora? Pero creo que estoy realmente emocionado por el IDE. Creo que será una dulce extensión. Mark, ¿querías decir algo? Sí, algo que se relaciona tanto con lo que confunde a la gente como con el lado de la educación hacia adelante.

El error número uno que veo que la gente comete con el modelo mental de React es no darse cuenta de que cuando React renderiza un componente, volverá a renderizar recursivamente cada componente hijo dentro de ese por defecto. Es como React siempre ha funcionado. Y mucha gente ha asumido a lo largo de los años que, oh, mi componente hijo solo se vuelve a renderizar cuando sus props realmente han cambiado. Mi publicación de blog más útil es un artículo de 12,000 palabras sobre el comportamiento de renderizado de React. Y mucho de eso fue solo que sigo viendo a la gente hacer estas mismas preguntas o cometer estos errores una y otra vez. Y entonces, lo del compilador de React es que realmente invierte ese comportamiento predeterminado en su cabeza.

Y por primera vez, React realmente solo volverá a renderizar tu componente hijo cuando su comportamiento cambie o cuando sus props realmente cambien. Y como decía Theo, aquellos de nosotros que hemos estado usando React durante mucho tiempo realmente necesitamos cambiar nuestra comprensión del sistema. Sí, estoy de acuerdo. Solo una adición muy breve. La magia solo es magia cuando funciona el 99.9% del tiempo. Cuando funciona el 100% del tiempo, eso es simplemente la forma en que las cosas funcionan. No pensamos en el hecho de que la luz que nos ilumina ahora mismo es magia. Magia absoluta. Y la primera vez que alguien la vio, era magia. Pero sí, creo que una vez que lleguemos al lugar donde lo único que tienes que aprender es la forma en que las cosas están destinadas a funcionar, entonces eventualmente puedes revelar progresivamente. Puedes bajar para subir, etcétera. Pero creo que se sentirá como magia por un tiempo, y luego lo daremos por sentado de la mejor manera posible. Acabo de tener esto en mi charla. Debería haber comenzado mi charla sobre streaming con, por cierto, voy a entrar en todos los detalles minuciosos sobre cómo funciona esto. No necesitas saber nada de esto.

Y olvidé decir eso. Terminé recibiendo un montón de preguntas sobre cómo depurar estos comportamientos específicos. No tienes que hacerlo. En realidad, simplemente funciona, por loco que parezca. Y aceptar eso y probarlo y no preocuparse hasta que te encuentres con ese error que no tiene sentido puede hacer que muchas de estas cosas sean mucho más accesibles.

Tengo una pregunta picante, que comenzaré con Mark, solo por seguridad. Él es el más seguro para responder una pregunta picante. Sí, al menos esta. No Tom. De acuerdo. Aquí está. React se ha vuelto dependiente de frameworks como Next.js para algunas de sus características recientes. ¿Qué piensas sobre eso? ¿Cuál es tu opinión al respecto? ¿Cómo te sientes acerca de que React destaque o favorezca algunos de estos frameworks?

No se trata tanto de que yo tenga opiniones al respecto como de estar dentro de una especie de círculo no tan interno como para ver lo que ha estado sucediendo. Así que voy a ponerme mi sombrero de no soy un empleado de Facebook, pero estoy interpretando uno. El equipo de React siempre pudo probar en alfa y beta las características usando la propia infraestructura interna de Facebook meta. Así que, dado que Facebook tiene su propia infraestructura de servidor, los componentes de servidor fueron la primera característica donde realmente no pudieron hacer eso. Así que entre tal vez como intentar difundir un poco del conocimiento y la propiedad de React fuera de una sola empresa, así como Vercell queriendo, ya sabes, como el equipo de React convenció a Vercell de comprar su visión, pero también Vercell estaba dispuesto a poner su dinero donde estaba su boca y pagar a los empleados y reconstruir Next, etcétera. Así que entiendo algunas de las preocupaciones y quejas de la comunidad sobre, ya sabes, Vercell tratando de vender servidores o lo que sea, pero también entiendo que tenía sentido desde una perspectiva de desarrollo, desde una perspectiva de progreso de la empresa, y en última instancia, necesitaban poder construir estas cosas y probarlas.

¿Puedo dar la versión más picante? Por supuesto. Next fue el primer framework en apostar todo por RSCs, porque Next fue el framework con la peor ergonomía en cuanto a enrutamiento, diseños y obtención de datos por mucho. Era tan malo. Y necesitaba componentes de servidor para funcionar, para poder existir en la próxima generación, mucho menos competir en ella. Los otros frameworks lo intentaron. Hydrogen lo intentó muy temprano, demasiado temprano, y sufrió mucho por ello. Remix lo intentó, no estaba seguro, y tuvo como idas y venidas al respecto. Ahora están entrando. Next fue el que más lo necesitaba y también el más dispuesto. Y creo que por eso fueron elegidos. Más que porque gastaron el dinero o lo que sea. Y diría que se eligieron a sí mismos.

Así que no fue como si el equipo de React dijera, de acuerdo, vamos a elegir Next. Fue más bien, hey, frameworks, necesitamos algo de ayuda para probar estas cosas. Y Next fue el que tenía los recursos para hacerlo, y también, supongo, la motivación también. Yo estaba en el equipo de Remix en ese momento, y Ryan, Michael y yo, principalmente Ryan, preparamos una demostración de lo que Remix puede hacer ahora y lo que RSCs con Remix puede hacer ahora, y no estaba allí todavía. Y con un equipo tan pequeño, no teníamos los recursos para dedicarnos a llevarlo allí, y Remix era bastante bueno en ese momento. Todavía lo es. Así que sí, creo que eso es lo que influyó. Pero estoy súper emocionado de tener RSCs en React, Revit, V7 y Remix. Sí, creo que una de las cosas que nos dimos cuenta trabajando en React en Meta, llegamos al límite de lo que podíamos hacer con una arquitectura solo de cliente. Realmente necesitábamos incorporar el servidor en la ecuación. Y Facebook se beneficia de tener control tanto del cliente como del servidor. Puedes enviar diferentes cargas, puedes inventar un nuevo esquema de serialización que pueda serializar mágicamente promesas a través del cable, lo cual es simplemente una locura. Pero tienes que tener control o influencia sobre la infraestructura del servidor y el cliente para poder hacerlo. Y el empaquetado también. Eso es correcto. Así que creo que Vercel, la idea de que podrías tener infraestructura gestionada que terminas construyendo en conjunto. Así que tienes una cohesión muy alta entre la infraestructura gestionada y el framework. Creo que lo posicionó de manera única para poder trazar el rumbo un poco aquí. Pero el ideal es que esa infraestructura gestionada altamente cohesionada y el framework estén débilmente acoplados. Así que otros frameworks funcionan realmente bien en Vercel. Y la infraestructura gestionada se puede usar para potenciar cualquier cosa, desde Python hasta PHP o cualquier JavaScript que puedas sacar. Pero creo que necesitas tener influencia tanto en el servidor como en el cliente para lograr los próximos hitos que estamos tratando de alcanzar.

¿Puedo añadir algo? Porque Dan siempre me ha pedido que diga esto. No tienes que usar un servidor en tiempo de ejecución para RSCs. Así que está bien, pero probablemente deberías. Moffy, ¿querías añadir algo? Estoy bien. De acuerdo. Genial.

Pregunta final, justo antes de terminar, para cualquiera que sea nuevo en React, ¿qué consejos y sugerencias les darías para comenzar con React? Ve a leer el tutorial de la documentación oficial. Sí. Más uno. Es tan bueno. Y simplemente construye cosas. No te pierdas demasiado en todos estos detalles. No intentes aprender cómo funcionan todas estas nuevas características en su totalidad. La mayoría de nosotros, las personas aquí que trabajamos en React, no entendemos completamente estas características. No necesitas aprender todo React para ser un desarrollador de React. Necesitas construir cosas con React para ser un desarrollador de React. ¿Alguien va a promocionar epic React? Maldición. Sí. Moffy, Ellie? Quiero decir, apoyo nuestra documentación, así que... La documentación es genial. Genial. Muy bien, amigos.

¿Algún pensamiento final? Amo a estos chicos. Sam? ¿Dónde puedo obtener más información sobre React IDE? Creo que no me han incluido en algunas reuniones recientemente. Quiero agradecer a la comunidad. Esto es algo bastante único para React. Pensando en nuestra asociación con Vercel y otras empresas, como Microsoft... React es mucho más grande que las limitaciones que tenemos. Esta no sería la comunidad que estaría aquí, los eventos que estarían aquí, si no estuviéramos todos trabajando juntos para impulsar estas cosas hacia adelante. No quieres las limitaciones de meta.

No queremos que todos ustedes tengan que usar PHP para los componentes del servidor. Así que necesitamos trabajar con una comunidad, necesitamos las limitaciones adicionales, y esto hace que React sea mejor para todos. Educación, influencia en YouTube, todo esto es lo que hace a la comunidad la comunidad. Gracias por sus contribuciones a todo eso.

Bien dicho. Y gracias a Eli por seguir impulsando esto. Sé que no siempre ha sido lo más fácil en una gran empresa ser como... Sí, necesitamos apostar por esta cosa de código abierto y esta comunidad y tener estos eventos y hacer todas estas cosas. A Fang no le encanta eso, y estás empujando muy fuerte, y lo reconocemos. Así que obviamente, un aplauso para la comunidad, pero más importante, para Eli y para todo el equipo por hacer todo esto posible.

En esa hermosa nota, muchas gracias por unirse a este panel y por sus opiniones picantes y dulces. Y gracias a ustedes, por unirse a nosotros y ser parte de la audiencia. Gracias. Gracias.