¿Deberías usar React en 2023?

Entonces, hola a todos. Entonces, sí, estamos aquí para hablar sobre no usar apt-router. Jordan, Jordan. Charla equivocada. Lo siento mucho.

Bueno, entonces nuestra charla es, estamos en el año 2023. Y te estás preguntando, ¿debería usar React? Sí. Entonces, hola, soy True. Soy ingeniero de software en Discord, trabajando en la aplicación Discord. Así que construyo características en React y React Native. Y un dato curioso, usé React por primera vez en Uber cuando era pasante allí en 2016.

Y yo soy Jordan. No tengo idea de qué es esta foto mía. Soy líder técnico en MissinLabs. Construyo productos de front-end y formo equipos de front-end allí. Y creo que la primera vez que usé React fue en Nike en 2014. Sí.

Entonces, sí, React es muy popular. Y para muchos de nosotros, en realidad se ha convertido en la elección predeterminada. Especialmente dado que esto es la Cumbre de React, estoy seguro de que para muchos de nosotros, es la elección predeterminada. Pero tal vez has visto este discurso de framework en Twitter. Tal vez has seguido un video de YouTube de clickbait. Y te ha estado diciendo que React está muerto, no deberías estar usándolo. Es lento. Es feo. Es difícil de aprender. Y hay un nuevo framework hermoso que resolverá todos tus problemas. Y eso es lo que deberías estar usando en su lugar. Deberías sentirte mal por usar React. Y estoy seguro de que muchos de nosotros tenemos una respuesta a esta pregunta.

¿Deberías usar React en 2023? Y supongo que la respuesta es sí, dado el nombre de esta conferencia. Pero esta pregunta, la hemos visto cada vez más, especialmente de personas que son más nuevas en la comunidad. Y realmente no entienden la sutileza de esa discusión que ha estado ocurriendo. Y a medida que React cumple 10 años, es hora de mirar a nuestro bebé de 10 años y decir, ¿está funcionando? Y realmente hacer la pregunta fundamental... ¿Deberías usar React en 2023? Y entonces, afortunadamente, estamos aquí para darte la respuesta definitiva que se aplica a todos los que hacen esta pregunta. Quizás. Sí. Quizás. No lo sé. ¿Por qué lo sabría yo? Depende. Sí, es... Sí, quizás. Entonces, sí. Pero como siempre, pueden aplicarse términos y condiciones.

Entonces, realmente, lo que estamos tratando de decir es que uses React si tiene sentido para ti. Y esto parece una evasiva. Parece que solo queríamos un viaje gratis a Ámsterdam. Pero realmente hay un mensaje subyacente aquí. No todos tienen las mismas necesidades, los mismos casos de uso y los mismos criterios de evaluación cuando miran los frameworks. Y cuando estás tomando una decisión como esta, es realmente importante entender cómo vas a evaluar tus opciones, y separar la señal del ruido. Estas decisiones generalmente no se toman en un vacío, y hay tanta sutileza que entra en eso que puede perderse en este discurso en línea. Y entonces, para entender lo que queremos decir con esto, primero entendamos por qué pensamos que React sigue siendo una gran elección en 2023.

Sí, React sigue siendo genial, no te preocupes. Entonces, el primer gran tema es la familiaridad. Entonces, hago streaming en Twitch, y construyo muchos sitios web. Y entonces, uso React para la mayoría de ellos, porque es con lo que estoy más familiarizado. Y parece super obvio, pero es una buena razón. Es una buena razón. Entonces, conocer React me ayuda a construir más rápido, así que en lugar de aprender en el stream, puedo realmente tener salida de código. Entonces, en el contexto de los pequeños proyectos que construyo en Twitch, esta podría ser la única razón por la que elijo React.

Pero, como extensión de esto, en una empresa más grande, la familiaridad significa que pasas menos tiempo contratando e incorporando. Entonces, si tienes ingenieros en tu equipo que ya están familiarizados con React, hace que sea una elección fácil de tomar. Y así, personalmente, también como desarrollador de React, cuando me uno a nuevas empresas que han utilizado React, hace que el proceso de incorporación sea mucho más fácil. Y así fue el caso para mí en Discord.

Sí, y en Mystin, hemos estado construyendo nuestros equipos de front-end, y nos hemos inclinado bastante hacia React. Tenemos un conjunto de productos completamente React, y nuestros tiempos de incorporación cuando contratamos solo, o personas que están familiarizadas con React, no solo contratamos desarrolladores de React, pero cuando contratamos personas que están familiarizadas con React, hemos encontrado que su incorporación se reduce drásticamente en cuestión de un par de días, son capaces de hacer contribuciones impactantes a nuestro código base, solo porque tenemos aplicaciones de React bastante estándar y están muy familiarizados con eso.

Además, debido a la enorme comunidad de React, la mayoría de los problemas en React ya han sido resueltos, y probablemente haya algún tutorial en Medium en internet que lo explique. React también tiene una muy buena documentación. Los nuevos documentos que se lanzaron recientemente, son muy buenos, un recurso muy útil, y se actualizan regularmente. Junto con los documentos, también hay mucho contenido educativo en internet en forma de videos de YouTube posts de blog, cursos, etc. También hay andamios, gratuitos y de pago, e incluso meta frameworks como Next.js y Remix que mejoran enormemente la experiencia de desarrollo de React. Todos estos vienen con configuraciones predeterminadas sensatas y configuraciones preconfiguradas, por lo que esto acelera tu proceso de desarrollo y la configuración. También proporcionan funcionalidad extendida más allá de lo que React ofrece de serie. Por ejemplo, Next tiene renderizado en el servidor, generación de sitios estáticos, rutas de API, división automática de código, y hay muchos recursos para construir sitios web con esos frameworks como Next y Remix. Sí, y la documentación en Next también es fantástica. Quiero decir, tienen ejemplos muy completos, siempre y cuando te asegures de estar en las páginas y no en el lado de la aplicación. Pero si te quedas allí, todo está bien. Sí, y junto con esa gran cantidad de recursos, también hay una cantidad insana de herramientas de código abierto y bibliotecas. Literalmente podrías nombrar cualquier cosa, y probablemente hay un paquete npm que te ayuda a construir en React. También podrías probablemente lanzar un sustantivo y existe un paquete npm, también. Sí, casi con seguridad. Así que algunos ejemplos muy conocidos de buenos recursos con React son Storybook, MUI, que al parecer no es MUI. Lo sé, lo aprendí ayer. He estado diciendo MUI toda mi vida. Hemos estado diciendo MUI mucho. Chakra, Radix, Headless UI, TanStack. Sí, que es su propio sub-ecosistema. Tienen TanStack router, TanStack table, TanStack esto, TanStack eso. Todo. Apollo Client, Jotai, Zestand, FrameRemotion, etc., etc.

Hay tantas opciones aquí. Sí, y la mejor biblioteca de clientes GraphQL, Relay, también está disponible en React. Probablemente una historia para otra charla, pero sí. También hay un paquete npm para cada carácter del alfabeto inglés, solo un carácter exportado a la vez. Sí, así que hay muchas de estas integraciones de terceros con React 2, muchos de los patrocinadores de esta conferencia, pero también proveedores de análisis, error monitoring, pruebas A-B testing. Esto es algo que he aprendido mientras lo he estado haciendo en MISTEN. No te creerías cuántos proveedores de análisis sin nombre también tienen enlaces e integraciones de React bastante profundas en el enrutador de React para proporcionar buenos análisis allí. Sí, y también hay muchos componentes de interfaz de usuario disponibles en el React ecosystem. Mencionaste algunos de ellos, pero incluso para casos de uso más complejos como Auth, hay empresas como Qlrk que proporcionan tanto servicios de Auth como una interfaz de usuario de Auth completa. Tienen componentes que te permiten crear organizaciones y cambiar de organizaciones en situaciones de gestión de organizaciones complejas, lo cual es algo loco de pensar que todo ese problema está resuelto ahora. Sí, es genial que no tengas que escribir ningún code. Sí, el mejor code que jamás escribí fue sin duda ningún code. Exactamente, así que, cuadra.

Entonces sí, y voy a decir algo que contradice una narrativa muy popular en este momento y es que React tiene un bastante buen rendimiento de fábrica. Claro, existen bibliotecas más eficientes y seguro que hay casos en los que React podría sufrir problemas de rendimiento, pero ¿quién no? Así que para la mayoría de las aplicaciones, React funciona muy bien.

Para profundizar en esto, existen muchos marcos de trabajo que mejoran la experiencia web de React, como Next y Remix, ellos existen, lo siento. Next.js tiene división automática de código, lo que mencioné anteriormente, lo que significa que los usuarios solo cargan el JavaScript necesario para la página que están viendo, y esto reduce drásticamente los tiempos de carga, y también utilizan la renderización del lado del servidor por defecto, por lo que aseguran que tengas la mejor experiencia de usuario por defecto para tu sitio. Y sí, estos marcos de trabajo tienen excelentes puntuaciones de Lighthouse de fábrica.

Sí, y también hay características de React que te dan mucha capacidad para ajustar el rendimiento, especialmente algunas de las más nuevas como Suspense y los Componentes del Servidor de React, que no quiero desempaquetar la controversia aquí, pero son formas que nos dan más formas de lidiar con el rendimiento de una manera más matizada. También hay proyectos como Astro por ahí, que han intentado este enfoque de islas para resolver el rendimiento, que es una forma interesante de verlo. En casos extremos, también puedes ser no exclusivo con React, esto es un poco interesante, pero siempre puedes escribir componentes críticos de rendimiento en otras bibliotecas, quizás más eficientes, como Quick o SolidJS y tenerlos integrados en tu árbol de React. La belleza de los marcos de trabajo basados en componentes es que el límite del componente termina siendo bastante bueno y es bastante fácil integrar entre marcos de trabajo. Y, obligatoriamente, como el equipo de React también te recordará, quizás haya un compilador de optimización. He estado escuchando eso durante años, pero resolverá todos nuestros problemas de rendimiento. Entonces, sí.

Y al final del día, probablemente tu aplicación ni siquiera se está enviando, entonces, ¿por qué estamos incluso hablando de performance? Sí. Y sí, algunas otras cosas que quiero mencionar, Discord ha encontrado a React Native súper útil porque usamos React. Y entonces, la capacidad de usar React Native y compartir code entre los dos es súper útil. Y entonces, en Discord, los ingenieros de producto son un poco diferentes. No hay, como, front end o back end. Todo el mundo hace un poco de todo en la pila. Entonces, por ejemplo, para mí, tengo que escribir React Native, tengo que hacer code nativo, todo eso. Y entonces, tener algo que pueda, como el conocimiento de React extendido al espacio de las aplicaciones móviles es súper útil para mí. Y entonces, realmente me gusta eso.

Sí. Y en Missyn, también hemos estado considerando a React Native para algunos de nuestros productos. Y tener una suite de productos que ya está construida en React hace que sea una propuesta mucho más sencilla. Sí. Exactamente. Entonces, sí. Quiero decir, esto suena bastante genial, ¿sabes? React es increíble. Sí, terminamos nuestra masterclass en diez minutos. Entonces, sí, podemos usar React para todo, ¿sabes? Quiero decir, nadie nunca fue despedido por elegir React. Sí, también dicen eso sobre Java. Pero, sí.

Entonces, demos un gran paso atrás. Y entendamos algo de la más sutileza aquí. Solo porque elijas React no significa que necesites elegir cada característica de React. Esto es un poco a lo que estábamos aludiendo antes con algo de la no exclusividad con performance. Hay muchas cosas que podrías no tener que usar en React. Hay muchas características nuevas y geniales como Server Component Suspense, pero está totalmente bien si nadie aquí está enviando una aplicación con eso. En la mayoría de los casos, en lo que quieres enfocarte es en construir tu producto y no en enfocarte demasiado en cómo estás construyendo tu producto. No te distraigas demasiado con la tecnología brillante. No estoy tratando de avergonzarte si lo haces. Yo me distraigo con la tecnología brillante todo el tiempo.

Paso mis fines de semana mirando cosas. Ella lo odia. Enfócate en lo que tiene sentido para ti. Realmente, lo que queremos llegar aquí es que React es una buena elección, pero no es la única. Hay muchos desarrolladores de React, pero también hay muchos de Vue, hay muchos de Svelte, hay muchos de Solid. Hay muchos paquetes de React en tooling, pero de manera similar para esos otros frameworks, hay muchos paquetes realmente buenos en tooling.

Hoy en día, cuando se trata de performance, parece que es una apuesta segura que las nuevas bibliotecas superan a React en alguna métrica de performance. Mirando a través de estos criterios de evaluación de los que hablamos antes, si tu equipo está completamente compuesto por desarrolladores de Vue de oficio, tal vez tenga sentido elegir Vue en lugar de elegir React. No tienes que optar por React solo porque tiene un gran ecosystem. Al final del día, es solo un conjunto de compensaciones. No hay una decisión objetivamente correcta o incorrecta que puedas tomar aquí. Tal vez en tu caso sí la hay, subjetivamente para ti, pero no hay un framework globalmente correcto con el que deberías estar trabajando. Es solo cuestión de mirar qué decisión tienes que tomar y mirar qué es importante para ti y evaluarlo contra eso.

Hay muchos desarrolladores realmente geniales por ahí que no usan React, y este es un punto que siempre trato de hacer. Incluso personalmente, me encanta Veep Press. Es un proyecto que se basa en Vue, y algunos de los proyectos favoritos que uso están documentados con Veep Press, pero realmente quiero seguir usando React, y eso es inaccesible para mí. Esa es una compensación con la que estoy cómodo, pero es una compensación al invertir solo en un ecosystem de React. Entonces, realmente, de lo que estamos hablando aquí es qué es importante para ti. Lo que hemos presentado aquí en realidad no es una razón para elegir React. Es un conjunto de criterios de evaluación que hemos mirado a través de la lente de React. Por ejemplo, hemos mirado la familiaridad, el ecosystem, el performance, el soporte nativo, pero hemos asumido que todos estos son igualmente importantes, y en la mayoría de los casos, no lo son. Tal vez la familiaridad es lo más importante en tu empresa, o tal vez el performance es realmente crítico, y necesitas tener una aplicación de performance que tal vez React no pueda satisfacer las necesidades de, y tal vez hay criterios de evaluación completamente diferentes de los que ni siquiera hemos hablado aquí, y es realmente subjetivo basado en dónde estás tomando esta decisión.

Así que permíteme darte un ejemplo, un ejemplo muy concreto, de cómo la importancia puede impactar estas decisiones. Así que antes de unirme a Misson Labs, en realidad trabajé en Netflix en nuestra aplicación de TV, y la aplicación de TV es una gran aplicación de React, hay un reconciliador personalizado de React que funciona con todas las plataformas de TV, es una locura. Trabajé en un equipo que específicamente miraba la memoria y el performance de esa aplicación de React, y uno de los mayores comentarios que recibimos de los usuarios y que vimos en los resultados de las pruebas A-B fue que el performance y la estabilidad eran básicamente los impulsores principales de la retención de usuarios en nuestras aplicaciones. Y la plataforma de TV tiene restricciones realmente interesantes. Estábamos usando un motor de JavaScript que creo que a estas alturas tiene 10 años, como un motor de JavaScript de 10 años, lo cual es una locura. No había forma de ejecutar JIT, y había todo tipo de restricciones interesantes con cómo se pintaban las imágenes en la pantalla, y miramos el modelo de renderizado de React y intersectamos con esas restricciones, terminó con mucha memoria que necesitaba ser recolectada por el recolector de basura. Realizamos algunos experimentos usando Svelte para ver si su architecture de compilador produciría mejoras, y lo que vimos fue que en realidad pasamos 10 veces menos tiempo en pausas de recolección de basura al aprovechar Svelte. Y vimos mejoras similares en el performance y mejoras generales en la memoria a lo largo del resto de la aplicación.

Y desafortunadamente, dejé Netflix antes de que pudiéramos realmente capitalizar estos hallazgos, pero cuando miramos esta migración, esta hipotética migración de React a Svelte, miramos nuestros criterios de evaluación y miramos un conjunto de compensaciones. ¿Estamos cómodos perdiendo el acceso a los paquetes de la comunidad que estábamos usando? Francamente, el paquete JSON en la aplicación de TV es alucinante. Es uno de los más grandes que he visto, y perderíamos el acceso a muchos de los paquetes de los que dependíamos anteriormente. Y seguro que había versiones de Svelte de algunas de las cosas que estábamos usando, pero no estaba al punto que estaba con React.

¿Estábamos dispuestos a incorporar a todos nuestros desarrolladores de React a Svelte? Esta es una gran pregunta. Todos fueron contratados para trabajar en una aplicación de React y ahora tenemos que averiguar cuáles son las mejores prácticas. Tenemos que averiguar día a día cómo vamos a enseñar a la gente a usar Svelte, cómo sería esa migración. Y vale la pena señalar que en casos extremos, cambios como este pueden llevar a la rotación de personal. La gente puede estar muy motivada acerca de sus frameworks de JavaScript y querrán seguir trabajando en una pila de tecnología con la que están familiarizados.

¿Y estábamos bien perdiendo el intercambio de código en el que habíamos dependido anteriormente? Netflix era una gran tienda de React y realmente no tendríamos la capacidad de compartir algunos de los componentes que habíamos estado antes. Especialmente dado que los otros equipos no estaban necesariamente motivados de la misma manera que nosotros para hacer este cambio. Y en Netflix, este conjunto de compensaciones era algo con lo que estábamos razonablemente cómodos. Había mucho tiempo y recursos que podríamos dedicar a un proyecto como ese. Pero si estás en una empresa que no necesariamente tiene el rendimiento como métrica número uno, o el tiempo o los recursos para invertir en algo como esto, estas compensaciones podrían aterrorizarte. Y eso está totalmente bien. Es por eso que es realmente clave tomar estas decisiones en el contexto de tu proyecto o empresa Entender qué compensaciones son importantes para ti y cuál es la importancia relativa de cómo estás evaluando tu proyecto.

Y lo otro es que, si te encuentras en una de estas situaciones muy específicas, similar a lo que hicimos con Netflix, tómate el tiempo y trata de usar datos para tomar esta decisión. Así que probablemente lo que quieras hacer es pasar tiempo evaluando cuáles son tus diferentes soluciones, viendo lo que te ofrecen y midiendo muy concretamente si están logrando lo que te propusiste que lograran. Esto es lo que hicimos en Netflix, existe un documento de más de treinta páginas en algún lugar internamente en Netflix, desearía todavía tener acceso a él, que capturó todas las sutilezas entre las diferentes formas de renderizado, las diferentes formas en que funcionaba el renderizado en estos dos frameworks y las alternativas que consideramos, y muy concretamente cuál sería el impacto de eso. Este es un modelo realmente bueno cuando estás tratando de tomar decisiones que van en contra de la corriente. Lo que quiero decir con esto es que si eres una empresa que utiliza principalmente React, estás tratando de convencer a la gente de usar algo más, esa es una decisión que va en contra de la corriente. Este tipo de decisiones tienden a tener una tonelada de inercia detrás de ellas. Generalmente tienes que poner energía en cambiar el rumbo de esa decisión. Y de manera similar a Netflix, cuando estaba en Square estábamos tomando la decisión de mover nuestra aplicación Ruby on Rails a algún framework de JavaScript. Tuve que hacer un análisis en profundidad de Svelte versus Preact, etc. Utilicé datos para compilar esto, mirando cosas como el tamaño del paquete, el tiempo de solicitud, todo eso. Los datos realmente me ayudaron a dar validez a mi elección. Terminé eligiendo Svelte. Pude usar eso y mostrar a las personas no técnicas cosas y señalarles datos para que se sientan mejor acerca de la elección. También ayuda a solidificar cuál será el impacto en el usuario.

Exactamente. Entonces, de todos modos, perdimos la ventaja aquí, pero React es genial. No intento decirte que React es malo. React tiene excelentes recursos, tiene excelentes paquetes. Tiene una gran comunidad. Todos estamos aquí ahora en esta masterclass. Pero también hay más allá. Estas decisiones, ya sabes, llevan mucho peso, así que piensa en lo que estás haciendo antes de tomar una decisión así. Pero en la mayoría de los casos, intenta concentrarte más en lo que estás construyendo y menos en cómo lo estás construyendo.

Y realmente, muy importante, trata de evitar el desarrollo impulsado por el FOMO. Esta es una tendencia que he visto cada vez más en Twitter. La mejor plataforma, supongo. Pero le sucede a los mejores de nosotros. Incluso a mí, el mejor de nosotros. Esto sucede muy frecuentemente. Y sabes, no solo con nuevas bibliotecas y frameworks, sino incluso con nuevas características en React. No te dejes llevar por el FOMO solo porque ves a alguien en Twitter usando algo que quizás quieras usar. No necesariamente significa que necesitas usar eso. Podrías seguir construyendo productos de la manera en que has estado construyendo productos. Pero también, tal vez piensa en lo que están usando, porque tal vez es bueno. Pero no lo sé. Como, sois un grupo inteligente de personas. Estoy seguro de que lo averiguaréis. Sí.

Entonces sí, de todos modos, muchas gracias a todos. Esta es una masterclass. Espero que todos hayan disfrutado de esta pequeña sutileza sobre por qué elegir React o no. Es controvertido, por supuesto, como dije en la apertura. Pero creo que has hecho una gran publicidad para React. Pensaba que serías más insistente, como, yendo, como, no, no, pero ¿Svelde? Quiero decir, sabes, pensé que teníamos que, ya sabes, darle una oportunidad a React dado que es la Cumbre de React.

Lo hago, quiero decir, a pesar de que también tengo una gran pasión por cosas fuera de React, todavía realmente amo React. Quiero decir, tuve la opción de usar cualquier otra cosa en mi nuevo trabajo cuando estábamos configurando las cosas. Todavía lo elijo por defecto. Creo que todavía es una excelente elección. Quiero decir, es solo que, ya sabes, no es lo único, ¿verdad?

¿Es esta agua de utilería o es agua real? Es agua real. Puedes agarrarla. También es un vaso real. Oh, genial. Sí. Pero una cosa importante es que tocaste al principio, creo, es que el tiempo de incorporación. Creo que React es, además de que es un gran framework y todo, también es una gran forma estandarizada de trabajar. Y de hecho, incluso en una gran base de code, como trabajo en Miro, tenemos unos cientos de desarrolladores de frontend y aún así las personas pueden incorporarse en cuestión de días. Y eso también es uno de los mayores poderes que creo, que tienes al usar cualquier framework probablemente. Y luego, hasta donde yo sé, React es por supuesto el mejor. ¿Estás de acuerdo? ¿Estás de acuerdo? ¿Sí?

Pero, ¿alguna vez te has sentado realmente con tu equipo como diste el ejemplo en Netflix, pero tal vez en Discord como, okay, para este nuevo producto, vamos a ir por el camino de Spelt o vamos por el camino de Angular, o? Ni siquiera sé cómo abordaría eso en Discord. Siento que mucha gente está muy aferrada a sus formas también. Y todo lo que tenemos en Discord se basa en React. React Native sería algo difícil de posicionar. Pero tal vez si hay un sitio de marketing o algo así, eso es algo que podría surgir. Pero sí, no. No creo que haya hecho eso demasiado. ¿Tú? Sí. El ejemplo en Netflix. Sí. Creo que también para mí, como no habíamos elegido realmente un stack de tecnología unificado. Había un proyecto en View, había un proyecto incipiente en Spelt de que la gente estaba hablando. Y luego había, o creo que la gente había estado hablando o había investigado sobre Spelt. Y luego había algunos proyectos de React. Y así que realmente no habíamos tomado una decisión para unificar. Cuando me uní, hablé con muchas personas en el equipo e hicimos la decisión consciente.

Entonces, como, vamos, ya sabes, queríamos elegir React. Y por muchas de las razones que hemos hablado. Como que sabíamos que tal vez hay proyectos de React Native en el futuro. Y realmente no vimos los beneficios que creo que algunos de los otros frameworks nos habrían dado, dado que todos estábamos familiarizados con React. Pero creo que si hubiéramos tenido esa discussion y todos fuéramos desarrolladores de View, el resultado habría sido muy diferente. Y creo que si hubiéramos tenido esa discussion y tuviéramos problemas de performance en nuestra aplicación o algo más, como creo que hemos—la narrativa de esa conversación habría sido muy diferente también. Así que es, es muy contextual.

Muy bien, gracias. Tenemos preguntas de la audiencia. Estoy disfrutando de mi propia conversación, pero no se supone que debo hacer esto.

Una pregunta de anónimo. ¿En qué caso crees que React podría ser objetivamente una mala elección? Sí, quiero decir, el caso que siempre se me ocurre es, bueno, no creo que sea nunca objetivamente malo. Creo que es tal vez contextualmente malo. ¿Tienes uno? Tengo uno. ¿Construir juegos con él? Tenemos una charla sobre alguien que construyó un juego propiamente dicho. Fue difícil. Pero creo que ya ha sido, ¿o no? ¿Esa charla ya ha sido? No, es el lunes. Creo que es el lunes. Sí, usé React 3 Fiber, fue una de las cosas más difíciles, fue muy humillante. Creo que el desarrollo de juegos es simplemente difícil. Lo sé, eso es cierto. ¿Cuál fue tu pieza? Creo que nunca es objetivamente malo, creo que es contextualmente malo. Creo que si estuviera trabajando en Bloomberg en su próxima generación de terminal, donde los tiempos de actualización de milisegundos importan, sabes, tal vez algo así, donde realmente te importa mucho. O tal vez, no sé. Estoy seguro de que hay muchos de estos casos extremos donde podría no beneficiarte, pero siempre tienes, creo que uno de los poderes de React es que tienes tantas formas de optar por no usarlo. Como, con Canvas, por ejemplo, React y Canvas tienen una, no son las cosas más estrechas para integrar. Entonces, si estás haciendo renderizado de Canvas, muchas veces simplemente optarás por no usar el ciclo de renderizado de React obteniendo una ref y haciendo mucha lógica imperativa allí. Creo que esa es la belleza de React, es que puedes optar por no usar su modelo de renderizado en muchos casos que normalmente dirías que es una mala decisión. Sí, úsalo donde lo quieras donde lo necesites y opta por no usarlo donde no lo necesites. E incluso, como hemos visto esta mañana con la charla de Misko, puedes simplemente acelerarlo y boom, aún obtienes el rendimiento. Sí, usamos Canvas de vez en cuando en Miro. ¿De vez en cuando? Sí. Sí. Pregunta de Alexander. ¿La charla Why Not App Router también está disponible? Está preguntando por un amigo. Lo siento, ¿qué? La charla que mencionaste al principio, Why Not App Router. Sí.

¿Qué pasa con eso? ¿Realmente existe? Existe en mi cabeza. Quiero decir, creo que AppRouter es genial. Creo que es divertido que estuviéramos hablando en contra de Lee, que es en parte por lo que pusimos la diapositiva allí, solo un pequeño golpe a él. Pero, sí, no creo que realmente tengamos ninguna objeción real aparte de, creo que es gracioso cuánta gente lo odia. También creo que es interesante ver a la gente en ambos lados, a favor y en contra, gradualmente perder la cabeza en Twitter, argumentando los mismos puntos una y otra vez. Creo que a la gente simplemente no le gusta el cambio, ¿verdad? Personalmente, me encanta. Di una masterclass sobre ello, me encanta.

Sí. Pregunta de Jay. ¿Cuál es el alcance de React en el futuro? No estoy seguro de lo que Jay quiere decir con esto. ¿Está Jay aquí? Tal vez Jay pueda elaborar, ¿o Jay está remoto? Jay remoto, ¿puedes elaborar? ¿Jay remoto? No, ¿Jay remoto? ¿Cuál es el alcance de React? Es una gran pregunta. En el futuro. Vamos a preguntarle a Lee. Vamos a preguntarle a Lee. Tendremos que preguntar a los chicos de ForSale. Gracias.

Bien, pregunta de Anónimo. Si tuvieras la total libertad para escribir Discord con un equipo lo suficientemente grande en cualquier framework, ¿te quedarías con React o saltarías a otro framework? Uf. Vale. No creo que lo que cambiaría es React, porque creo que obtenemos muchos buenos casos de uso de él, como Electron y todo eso, y luego React Native es súper útil. Hacemos mucho code nativo también, así que Objective-C, Swift, Kotlin, pero el lado de React Native ayuda mucho. Creo que lo que cambiaría es que usamos Flux para nuestras tiendas, y hay muchas tiendas. Así que encontraría una forma de minimizar eso. Hemos estado incorporando cosas como Zustand. ¿Eso es Zustand? No lo sé. Ese tipo de cosas. Pero aparte de eso, no creo que me quedaría con React. Creo que eso es lo que elegiría, sí. Además, Discord salió como en 2015, 2014, ¿verdad? ¿Es muy joven? Sí. No es tan viejo. Parece que ha estado aquí por siglos. Tal vez me equivoque. Simplemente se me ocurrió una fecha al azar. Nadie verifica los hechos. Espera, ¿qué harías tú? Si yo fuera React, ¿tú? ¿Has oído hablar de jQuery? Hey. Todavía es lo más grande que hay. Quiero decir, React es una fracción de la base de usuarios de jQuery.

Oh no, ¿sabes qué hago? Utilizo Rust. Y uso Tori. Bueno, eso es cierto, sí. Entonces todavía tienes que tener una capa de UI. Sí, eso es cierto. Eso es cierto. Rayos. Correcto. Rust. Compílalo a Wasm. Y luego haz que todo esté en Rust. Suena como un desarrollo impulsado por la seguridad adecuado justo ahí. Exactamente. Exactamente.

Aquí hay una pregunta de not-Teo. Not-Teo, así que Teo no está haciendo esta pregunta. Creo que Teo está remoto. ¿Cuál es tu opinión sobre TRPC? Oh. Entonces, está bien, lo usé hace mucho tiempo para un proyecto y fue súper, súper impresionante. Fue realmente fácil de usar. Soy realmente malo hablando sobre el lado técnico de las cosas, así que él fue el que me presentó a TRPC para ese proyecto si quieres hablar un poco sobre ello. Dato curioso, inventé TRPC antes de que fuera inventado. Está en mi GitHub. Se llama MagicAPI. Publicidad descarada. Quiero decir, es horrible. No lo uses. Pero, no, me encanta TRPC. Me gusta más GraphQL. Soy un gran fan de GraphQL.

Pero creo que TRPC resuelve muchos problemas, especialmente a menor escala. Creo... No puedo imaginar usando TRPC en una empresa del tamaño de Netflix, pero creo que TRPC es genial. Sí, incluso para muchas empresas. Es solo que, ya sabes, cuando tienes mil microservices y estás tratando de agregarlos en un gran gráfico, creo que TRPC no sería la mejor decisión.

Muy bien. Gracias. Sí. Y luego tenemos tiempo para una pregunta más. Y es de un gran visitante llamado Anónimo. ¿Qué enfoque deberíamos usar al implementar React en sistemas ya construidos? Por ejemplo, sistemas de gestión de servicios de TI. ¿Quieres responder a esta? No tengo muchas opiniones. Quiero decir, como el punto principal de la charla, que es, ya sabes, es una evasiva, pero es muy contextual, y cómo opera tu empresa es diferente. Quiero decir, como, ya sabes, el enfoque que tomé en Netflix, por ejemplo, fue, quiero decir, duró un año y todavía era una discussion en curso cuando me fui. Y hasta el día de hoy, un año después, todavía hay alguna discussion en curso sobre, ¿cuál es la próxima cosa? Así que no es una discussion fácil y cada empresa lo abordará de manera diferente. Pero de manera similar, en mi empresa actual, hemos hecho migraciones de view a react que fueron tan simples como ir a un grupo de personas y decir, oye, ¿estamos todos de acuerdo con esto, ¿verdad? Así que va a variar mucho según, ya sabes, el proceso de tu empresa, ya sabes, cómo, cuál es el alcance de estos proyectos, todo eso. Pero sí.

Muy bien, nos quedan menos 13 segundos. ¿Algún último comentario? Ninguno. Fue genial dar esta charla. Muchas gracias por invitarnos. Muy bien. Disfruta el resto de tu tiempo en Ámsterdam. Gracias.