¿Deberías usar React en 2023?

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

Los meta frameworks son cada vez más populares. La gente critica a React todo el tiempo. ¿Estás loco por seguir usando React? La charla va a cubrir cómo las empresas reales hacen esta evaluación de qué framework elegir. Se hablará de las ventajas de usar React, centrándose principalmente en los aspectos positivos pero también ofreciendo reflexiones constructivas sobre por qué podrías no querer hacerlo. ¿Deberías usar React en 2023?

31 min
02 Jun, 2023

Video Summary and Transcription

React es una opción popular, pero hay afirmaciones de que está muerto y debería ser reemplazado. React tiene un buen rendimiento de fábrica y es adecuado para la mayoría de las aplicaciones. React Native permite compartir código entre React y React Native. Al considerar una migración de React a Svelte, hay compensaciones a considerar. React ofrece una forma estandarizada de trabajar y una incorporación fácil.

Available in English

1. Introducción a React

Short description:

¡Hola a todos! En esta charla, discutiremos si deberías usar React. Tenemos dos oradores, True y Jordan, que compartirán sus experiencias con React. React es una opción popular, pero hay afirmaciones de que está muerto y debería ser reemplazado. Vamos a explorar este tema juntos.

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

Bien, nuestra charla es, es el año 2023. Y te preguntas, ¿debería usar React? Sí. Entonces, hola, soy True. Soy un ingeniero de software en Discord, trabajando en la aplicación de 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 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 armo equipos de front-end allí. Y creo que la primera vez que usé React fue en Nike en 2014. Sí.

Entonces, sí, React ciertamente es popular. Y para muchos de nosotros, se ha convertido en la opción predeterminada. Especialmente dado que esto es la Cumbre de React, estoy seguro de que para muchos de nosotros es la opción predeterminada. Pero tal vez hayas visto este discurso sobre el marco en Twitter. Tal vez hayas seguido un video de YouTube sensacionalista. Y te ha estado diciendo que React está muerto, que no deberías usarlo. Es lento. Es feo. Es difícil de aprender. Y hay algún nuevo marco 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.

2. Should you use React in 2023?

Short description:

¿Deberías usar React en 2023? Usa React si tiene sentido para ti. No todos tienen las mismas necesidades, casos de uso y criterios de evaluación. Comprende cómo evaluarás tus opciones y separa la señal del ruido. React sigue siendo excelente. La familiaridad es una buena razón para elegir React.

¿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 nuevas en la comunidad. Y realmente no entienden los matices de esa discusión que ha estado sucediendo. Y a medida que React cumple 10 años, es hora de mirar a nuestro bebé de 10 años y preguntarnos, ¿está funcionando? Y realmente hacer la pregunta fundamental... ¿Deberías usar React en 2023? Y así, afortunadamente, estamos aquí para darte la respuesta definitiva que se aplica a todos los que están haciendo esta pregunta. Tal vez. Sí. Tal vez. No lo sé. Depende. Sí, tal vez. Entonces, sí. Pero como siempre, pueden aplicarse términos y condiciones.

Entonces, en realidad, lo que estamos tratando de decir es que uses React si tiene sentido para ti. Y esto parece una excusa. 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 tomas una decisión como esta, es muy importante comprender cómo vas a evaluar tus opciones y separar la señal del ruido. Estas decisiones generalmente no se toman en el vacío, y hay tantos matices que se pierden en este discurso en línea. Y para entender lo que queremos decir con esto, primero entendamos por qué creemos que React sigue siendo una excelente opción en 2023.

Sí, React sigue siendo excelente, no te preocupes. El primer tema importante es la familiaridad. Y así, hago streaming en Twitch y construyo muchos sitios web. Y por eso, uso React para la mayoría de ellos, porque es con lo que estoy más familiarizado. Y parece muy obvio, pero es una buena razón. Es una buena razón. Y así, conocer React me ayuda a construir más rápido, así que en lugar de aprender en el stream, puedo realmente tener código de salida. Y así, 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.

3. Benefits of React and Available Resources

Short description:

La familiaridad con React puede ahorrar tiempo en contratación y capacitación, especialmente en empresas más grandes. La comunidad de React ofrece amplios recursos, incluyendo documentación, contenido educativo, andamios y metaframeworks como Next.js y Remix. Estas herramientas proporcionan configuraciones predeterminadas sensatas y funcionalidad extendida. Además, hay una amplia variedad de herramientas y bibliotecas de código abierto disponibles para construir con React, como Storybook, MUI, Chakra, Radix, Headless UI, TanStack, Apollo Client, Jotai, Zestand y FrameRemotion.

Pero, como una extensión de esto, en una empresa más grande, la familiaridad significa que se gasta menos tiempo en contratación y capacitación. Por lo tanto, si tienes ingenieros en tu equipo que ya están familiarizados con React, hace que sea una elección fácil de elegir. Y así, personalmente, también como desarrollador de React, cuando me uno a nuevas empresas que han utilizado React, el proceso de incorporación es mucho más fácil. Y así fue en Discord para mí.

Sí, en Mystin, hemos estado desarrollando nuestros equipos de front-end y nos hemos enfocado mucho en React. Tenemos una suite de productos completamente React, y cuando contratamos solo a personas que están familiarizadas con React, hemos descubierto que su incorporación se reduce drásticamente, en cuestión de unos días, pueden hacer contribuciones impactantes a nuestro código, simplemente porque tenemos aplicaciones React bastante básicas y ellos 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 Internet que lo explique. React también tiene una muy buena documentación. La nueva documentación que se lanzó recientemente es muy buena, es un recurso muy útil y se actualiza regularmente. Junto con la documentación, también hay mucho contenido educativo en Internet en forma de videos de YouTube, publicaciones de blogs, cursos, etc. También hay andamios gratuitos y de pago, e incluso metaframeworks como Next.js y Remix que mejoran en gran medida la experiencia de desarrollo de React. Todos ellos vienen con configuraciones predeterminadas sensatas y ajustes preconfigurados, lo que acelera tu proceso de desarrollo y configuración. También proporcionan funcionalidad extendida más allá de lo que React ofrece por defecto. Por ejemplo, Next tiene renderizado del lado del servidor, generación de sitios estáticos, rutas de API, división automática de código y hay muchos recursos sobre la construcción de 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 detallados, 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í, junto con esa enorme cantidad de recursos, también hay una cantidad increíble de herramientas y bibliotecas de código abierto. Literalmente puedes nombrar cualquier cosa y probablemente haya un paquete de npm que te ayuda a construir eso en React. Probablemente también puedas mencionar un sustantivo y exista un paquete de npm para eso también. Sí, casi con seguridad. Algunos ejemplos muy conocidos de buenos recursos con React son Storybook, MUI, que aparentemente no es MUI. Lo sé, lo aprendí ayer. Hemos estado diciendo MUI todo el tiempo. Chakra, Radix, Headless UI, TanStack. Sí, que es su propio subecosistema. Tienen TanStack router, TanStack table, TanStack esto, TanStack aquello. Todo. Apollo Client, Jotai, Zestand, FrameRemotion, etc., etc.

4. React Ecosystem Integrations

Short description:

En el ecosistema de React hay numerosas integraciones de terceros disponibles, incluyendo bibliotecas de clientes GraphQL como Relay. Muchos proveedores de análisis también ofrecen enlaces e integraciones con React, y hay una amplia gama de componentes de interfaz de usuario listos para usar. Empresas como Qlrk proporcionan servicios de autenticación y una interfaz de usuario de autenticación integrada, lo que facilita la gestión de organizaciones complejas.

Hay tantas opciones aquí. Sí, y la mejor biblioteca de clientes GraphQL, Relay, también está disponible en React. Probablemente sea una historia para otra charla, pero sí. También hay un paquete npm para cada carácter individual del alfabeto inglés, solo se exporta un carácter a la vez. Sí, por lo tanto, hay muchas de estas integraciones de terceros con React 2, muchos de los patrocinadores de esta conferencia, pero también proveedores de análisis, monitoreo de errores, pruebas A-B. Esto es algo que realmente he aprendido mientras trabajaba en MISTEN. No creerías cuántos proveedores de análisis sin nombre también tienen enlaces e integraciones con React y profundizan en el enrutador de React para proporcionar un buen análisis. Sí, también hay muchos componentes de interfaz de usuario listos para usar en el ecosistema de React. Mencionaste algunos de ellos, pero incluso para casos de uso más complejos como la autenticación, hay empresas como Qlrk que ofrecen tanto servicios de autenticación como una interfaz de usuario de autenticación completa. Tienen componentes que te permiten crear organizaciones y cambiar de organización en situaciones de gestión de organizaciones complejas, lo cual es algo increíble de pensar, que todo ese problema se haya resuelto ahora. Sí, es genial que no tengas que escribir ningún código. Sí, el mejor código que he escrito fue sin código, sin duda. Exactamente, así que tiene sentido.

5. React Performance and Integration

Short description:

React tiene un buen rendimiento de serie y es adecuado para la mayoría de las aplicaciones. Frameworks como Next.js y Remix proporcionan división automática de código y renderizado en el lado del servidor, lo que resulta en tiempos de carga mejorados y una mejor experiencia de usuario. Las características de React, como Suspense y React Server Components, ofrecen más formas de ajustar el rendimiento. Otras bibliotecas como Quick y SolidJS se pueden integrar con React para componentes críticos en rendimiento. La naturaleza basada en componentes de React permite una fácil integración entre frameworks.

Sí, y voy a decir algo que contradice una narrativa muy popular en este momento y es que React tiene un rendimiento bastante bueno de serie. Claro, hay bibliotecas más eficientes y ciertamente hay algunos casos en los que React podría tener problemas de rendimiento, pero ¿quién no los tiene? Así que para la mayoría de las aplicaciones, React funciona muy bien.

Para profundizar en esto, muchos frameworks que mejoran la experiencia web de React, como Next y Remix, existen, lo siento. Next.js tiene división automática de código, que mencioné antes, 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 el renderizado en el lado del servidor de forma predeterminada, por lo que aseguran que tengas la mejor experiencia de usuario predeterminada para tu sitio. Y sí, las puntuaciones de Lighthouse de estos frameworks son excelentes de serie.

Sí, 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 React Server Components, de las que no quiero profundizar en la controversia aquí, pero son formas que nos brindan más formas de lidiar con el rendimiento de manera más matizada. También hay proyectos como Astro que han intentado este enfoque de islas para resolver el rendimiento, lo cual es interesante. En casos extremos, también puedes ser no exclusivo con React, esto es un poco interesante, pero siempre puedes escribir componentes críticos en rendimiento en otras bibliotecas, tal vez más eficientes como Quick o SolidJS y tenerlos integrados en tu árbol de React. La belleza de los frameworks basados en componentes es que el límite del componente termina siendo bastante bueno y es bastante fácil de integrar entre frameworks. Y, obligatoriamente, como también te recordará el equipo de React, tal vez haya un compilador de optimización. He estado escuchando eso durante años, pero resolverá todos nuestros problemas de rendimiento. Así que sí.

6. React Native and Building Products

Short description:

React Native es muy útil porque permite compartir código entre React y React Native. En Discord, los ingenieros de producto trabajan tanto en el front-end como en el back-end. El conocimiento de React se extiende al espacio de aplicaciones móviles, lo cual es beneficioso. Missyn también considera React Native para sus productos. React es una excelente elección y está bien no utilizar todas las características. Enfócate en construir tu producto y no te distraigas con tecnología brillante.

Y al final del día, es probable que tu aplicación ni siquiera se esté lanzando, entonces, ¿por qué estamos hablando de rendimiento? Sí. Y sí, algunas otras cosas que quiero mencionar, Discord ha encontrado que React Native es súper útil porque usamos React. Y así, la capacidad de usar React Native y compartir código entre los dos es súper útil. En Discord, los ingenieros de producto son un poco diferentes. No hay, como, front-end o back-end. Todos hacen todas las partes del stack. Por ejemplo, para mí, tengo que escribir React Native, tengo que hacer código nativo, todo eso. Y así, tener algo en lo que puedo, como el conocimiento de React se extiende al espacio de aplicaciones móviles, es súper útil para mí. Y así, realmente me gusta eso.

Sí. Y en Missyn, también hemos estado considerando React Native para algunos de nuestros productos. Y tener un conjunto de productos que ya está construido en React hace que sea una propuesta mucho más simple. Sí. Exactamente. Entonces, sí. Quiero decir, esto suena bastante bien, ¿sabes? React es increíble. Sí, terminamos nuestra charla 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 comprendamos algunos de los matices aquí. Solo porque elijas React no significa que necesites elegir todas las características de React. Esto es a lo que nos referíamos antes con la no exclusividad del rendimiento. Hay muchas cosas que es posible que no tengas que usar en React. Hay muchas características nuevas geniales como Suspense de Componentes del Servidor, pero está totalmente bien si nadie aquí está lanzando una aplicación con eso. En la mayoría de los casos, lo que quieres enfocarte es en construir tu producto y no obsesionarte demasiado con cómo lo estás construyendo. No te distraigas demasiado con tecnología brillante. No intento avergonzarte si lo haces. Yo también me distraigo con tecnología brillante todo el tiempo.

7. Choosing the Right Framework

Short description:

React es una buena opción, pero no es la única opción. Hay muchos desarrolladores de React, pero también hay muchos desarrolladores de Vue, Svelte y Solid. En cuanto al rendimiento, parece que es común que las nuevas bibliotecas superen a React en alguna métrica de rendimiento. No hay una decisión objetivamente correcta o incorrecta que puedas tomar aquí. Lo que hemos presentado aquí no es realmente una razón para elegir React. Es un conjunto de criterios de evaluación a través de los cuales hemos analizado React. Tal vez la familiaridad sea lo más importante en tu empresa, o tal vez el rendimiento sea realmente crítico. Es realmente subjetivo según dónde tomes esta decisión. Permíteme darte un ejemplo de cómo la importancia puede afectar estas decisiones. Antes de unirme a Misson Labs, trabajé en Netflix en nuestra aplicación de TV, y una de las principales críticas que recibimos de los usuarios fue que el rendimiento y la estabilidad eran los principales impulsores de la retención de usuarios en nuestras aplicaciones. Realizamos algunos experimentos utilizando Svelte y vimos mejoras significativas en el rendimiento y la memoria.

Paso mis fines de semana investigando cosas. A ella no le gusta. Concéntrate en lo que tiene sentido para ti. En realidad, lo que queremos destacar aquí es que React es una buena opción, pero no es la única opción. Hay muchos desarrolladores de React, pero también hay muchos desarrolladores de Vue, Svelte y Solid. Hay muchas bibliotecas de React en las herramientas, pero lo mismo ocurre con los otros frameworks, hay muchas bibliotecas realmente buenas en las herramientas.

En estos días, cuando se trata de rendimiento, parece que es común que las nuevas bibliotecas superen a React en alguna métrica de rendimiento. Al analizar estos criterios de evaluación que mencionamos antes, si tu equipo está compuesto exclusivamente por desarrolladores de Vue, tal vez tenga sentido elegir Vue en lugar de React. No tienes que optar por React solo porque tiene un gran ecosistema. 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 haya una decisión subjetiva para ti, pero no hay un framework globalmente correcto con el que debas trabajar. Solo se trata de analizar qué decisión debes tomar y qué es importante para ti y evaluarlo en función de eso.

Hay muchos desarrolladores realmente buenos que no usan React, y este es un punto que siempre trato de mencionar. Incluso personalmente, me encanta Veep Press. Es un proyecto basado en Vue, y algunos de los proyectos favoritos que uso están documentados con Veep Press, pero realmente quiero seguir usando React, y eso me resulta inaccesible. Es una compensación con la que me siento cómodo, pero es una compensación al invertir solo en un ecosistema de React. Entonces, realmente, de lo que estamos hablando aquí es de lo que es importante para ti. Lo que hemos presentado aquí no es realmente una razón para elegir React. Es un conjunto de criterios de evaluación a través de los cuales hemos analizado React. Por ejemplo, hemos analizado la familiaridad, el ecosistema, el rendimiento, el soporte nativo, pero hemos asumido que todos son igualmente importantes, y en la mayoría de los casos, en realidad no lo son. Tal vez la familiaridad sea lo más importante en tu empresa, o tal vez el rendimiento sea realmente crítico y necesites una aplicación de alto rendimiento que React tal vez no pueda satisfacer tus necesidades, y tal vez haya criterios de evaluación completamente diferentes de los que ni siquiera hemos hablado aquí, y es realmente subjetivo según dónde tomes esta decisión.

Permíteme darte un ejemplo, un ejemplo muy concreto, de cómo la importancia puede afectar estas decisiones. Antes de unirme a Misson Labs, 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 de React personalizado que funciona con todas las plataformas de TV, es algo loco. Trabajé en un equipo que se enfocaba específicamente en la memoria y el rendimiento de esa aplicación de React, y una de las principales críticas que recibimos de los usuarios y que vimos en los resultados de las pruebas A-B fue que el rendimiento y la estabilidad eran básicamente los principales impulsores de la retención de usuarios en nuestras aplicaciones. La plataforma de TV tiene restricciones realmente interesantes. Estábamos utilizando un motor de JavaScript que creo que en este momento tiene 10 años, como un motor de JavaScript de 10 años, lo cual es increíble. No había forma de ejecutar JIT, y había todo tipo de restricciones interesantes con respecto a cómo se pintaban las imágenes en la pantalla, y analizamos el modelo de renderizado de React y cómo se intersectaba con esas restricciones, y terminamos con una gran cantidad de memoria que necesitaba ser recolectada por el recolector de basura. Realizamos algunos experimentos utilizando Svelte para ver si su arquitectura 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 rendimiento y mejoras generales de memoria en el resto de la aplicación.

8. Trade-offs in React to Svelte Migration

Short description:

Al considerar una migración de React a Svelte, hay compensaciones a tener en cuenta. Perder el acceso a paquetes de la comunidad y capacitar a los desarrolladores de React en Svelte puede ser un desafío. El intercambio de código y la motivación de otros equipos también juegan un papel. Estas compensaciones dependen del contexto de tu proyecto. Utilizar datos para tomar decisiones y evaluar diferentes soluciones puede ayudar a solidificar tu elección.

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

¿Estamos dispuestos a capacitar a todos nuestros desarrolladores de React en 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 cómo vamos a enseñar a las personas a usar Svelte en su día a día, cómo se vería esa migración. Y vale la pena señalar que en casos extremos, cambios como este pueden llevar a la pérdida de personal. Las personas pueden estar muy motivadas por sus frameworks de JavaScript y pueden querer seguir trabajando en una pila tecnológica con la que están familiarizadas.

¿Estamos dispuestos a perder el intercambio de código en el que dependíamos anteriormente? Netflix era un gran usuario de React y no tendríamos realmente la capacidad de compartir algunos de los componentes que teníamos anteriormente. Especialmente porque los otros equipos no estaban necesariamente motivados de la misma manera que nosotros para realizar 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 podíamos dedicar a un proyecto como ese. Pero si estás en una empresa que no tiene necesariamente el rendimiento como una métrica principal, o el tiempo o los recursos para invertir en algo así, estas compensaciones podrían asustarte. Y eso está totalmente bien. Es por eso que es realmente importante tomar estas decisiones en el contexto de tu proyecto o empresa. Comprender 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, si te encuentras en una de estas situaciones muy específicas, similar a lo que hicimos en Netflix, tómate el tiempo y trata de utilizar datos para tomar esta decisión. Lo que probablemente quieras hacer es dedicar tiempo a evaluar cuáles son tus diferentes soluciones, ver qué te ofrecen y medir de manera muy concreta si realmente están logrando lo que te propusiste lograr. Esto es lo que hicimos en Netflix, hay un documento de más de treinta páginas que existe en algún lugar internamente en Netflix, ojalá todavía tuviera acceso a él, que capturaba todas las sutilezas entre las diferentes formas de renderizado en estos dos frameworks y las alternativas que consideramos, y de manera muy concreta 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 y estás tratando de convencer a las personas de usar algo diferente, esa es una decisión que va en contra de la corriente. Estos tipos de decisiones tienden a tener mucha 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 trasladar nuestra aplicación de Ruby on Rails a algún framework de JavaScript. Tuve que hacer un análisis exhaustivo 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 personas no técnicas cosas y señalarles los datos para que se sientan mejor con la elección. También ayuda a solidificar cuál será el impacto en el usuario.

9. Final Thoughts on React

Short description:

React es genial. Tiene excelentes recursos, paquetes y una comunidad solidaria. Al tomar decisiones, considera la importancia que tienen y enfócate en lo que estás construyendo. Evita el desarrollo impulsado por FOMO y no te sientas presionado para adoptar nuevas tecnologías solo porque otros las están usando. Gracias a todos por asistir a esta charla sobre la elección de React. Es controvertido, pero está claro que React tiene muchas ventajas.

Exactamente. De todos modos, perdimos el hilo aquí, pero React es genial. No estoy tratando de decirte que React es malo. React tiene excelentes recursos, tiene excelentes paquetes. Tiene una gran comunidad. Todos estamos aquí en esta charla. Pero también hay más opciones disponibles. Estas decisiones, ya sabes, tienen 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 enfocarte más en lo que estás construyendo y menos en cómo lo estás construyendo.

Y realmente, es muy importante tratar de evitar el desarrollo impulsado por 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 todos nosotros. Esto sucede con mucha frecuencia. 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 tal vez quieras usar. No necesariamente significa que debas usarlo. Puedes seguir construyendo tu producto de la forma en que lo has estado construyendo. Pero también, tal vez piensa en lo que están usando, porque tal vez sea bueno. Pero no lo sé. Eres un grupo inteligente de personas. Estoy seguro de que lo descubrirán. Sí.

En fin, muchas gracias a todos. Esta es una charla. Espero que todos hayan disfrutado de esta pequeña sutileza sobre por qué elegir React o no. Es controvertido, por supuesto, como dije al principio. Pero creo que realmente han hecho un gran anuncio para React. Pensé que serían más insistentes, como diciendo, no, no, pero ¿Svelte? Quiero decir, sabía que teníamos que, ya sabes, darle algo a React dado que es la Cumbre de React.

10. React, Onboarding, and Choosing Frameworks

Short description:

A pesar de tener una pasión por cosas fuera de React, todavía me encanta. React es una excelente opción, pero no es lo único. React ofrece una forma estandarizada de trabajar y una incorporación fácil. Sin embargo, al elegir entre diferentes frameworks, puede ser desafiante cambiar el stack tecnológico establecido. Unificar el stack tecnológico requiere una consideración cuidadosa y discusiones con el equipo.

Lo hago, quiero decir, a pesar de tener una gran pasión por cosas fuera de React, todavía me encanta React. Quiero decir, tenía 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 sigue siendo una excelente opción. Quiero decir, es solo que, ya sabes, no es lo único, ¿verdad?

¿Es esto agua de adorno o es agua real? Es agua real. Puedes tomarla. También es un vaso real. Oh, genial. Sí. Pero una cosa importante que mencionaste al principio, creo, es el tiempo de incorporación. Creo que React, además de ser un excelente framework y todo, también es una gran forma estandarizada de trabajar. Y de hecho, incluso en una base de código grande, como en Miro, tenemos varios cientos de desarrolladores frontend y aún así las personas pueden incorporarse en cuestión de días. Y eso también es una de las mayores fortalezas que creo que tienes al usar cualquier framework probablemente. Y hasta donde 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, bueno, para este nuevo producto, vamos 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 muchas personas están muy arraigadas en sus formas también. Y todo lo que tenemos en Discord se basa en React. Sería difícil posicionar React Native. Pero tal vez si hay un sitio de marketing o algo así, eso podría surgir. Pero sí, no. No creo que haya hecho eso demasiado. ¿Tú sí? Sí. El ejemplo en Netflix. Sí. Creo que también para mí, como no habíamos elegido un stack tecnológico unificado. Había un proyecto en View, había un proyecto incipiente en Spelt del que la gente estaba hablando. Y luego había, o creo que la gente había estado hablando o investigando Spelt. Y luego había algunos proyectos en React. Y así que no habíamos tomado una decisión de unificar. Cuando me uní, hablé con muchas personas del equipo y tomamos la decisión consciente.

11. Contextual Considerations for Choosing React

Short description:

Queríamos elegir React porque estábamos familiarizados con él y veíamos potencial para futuros proyectos de React Native. El resultado hubiera sido diferente si fuéramos desarrolladores de View o tuviéramos problemas de rendimiento. La decisión es altamente contextual.

Entonces, como, solo queríamos elegir React. Y por muchas de las razones que hemos mencionado. Sabíamos que tal vez habría 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 discusión y todos fuéramos desarrolladores de View, el resultado habría sido muy diferente. Y creo que si hubiéramos tenido esa discusión y hubiéramos tenido problemas de rendimiento en nuestra aplicación o algo más, creo que la narrativa de esa conversación también sería muy diferente. Así que es, es muy contextual.

QnA

React's Contextual Suitability and Opting Out

Short description:

React nunca es objetivamente malo, pero hay casos contextuales donde puede que no sea la mejor opción. Por ejemplo, en el desarrollo de juegos puede ser desafiante. Si los tiempos de actualización en milisegundos son cruciales, React puede no ser la opción ideal. Sin embargo, React ofrece flexibilidad, permitiendo a los desarrolladores optar por no utilizar su modelo de renderizado en ciertos casos. Es importante utilizar React donde sea necesario y optar por no utilizarlo donde no lo sea. React aún puede ofrecer un buen rendimiento, como se muestra en la charla de Misko. A veces, se utiliza Canvas junto con React en Miro. Una pregunta de Alexander pregunta sobre la disponibilidad de la charla sobre Why Not App Router.

De acuerdo, gracias. Tenemos preguntas de la audiencia. Estoy disfrutando de mi propia conversación, pero no se supone que debo hacerlo.

Una pregunta de un anónimo. ¿En qué caso de uso crees que React podría ser objetivamente una mala elección? Sí, quiero decir, el caso que siempre se me ocurre es... bueno, está bien, no creo que sea objetivamente malo. Creo que es contextualmente malo. ¿Tienes alguno? Tengo uno. ¿Construir juegos con él? Tenemos una charla sobre alguien que construyó un juego real. Fue difícil. Pero creo que ya ha sido, ¿o no? ¿Ya ha sido esa charla? No, es el lunes. Creo que es el lunes. Sí, utilicé React 3 Fiber, fue uno de los 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 opinión? Creo que nunca es objetivamente malo, creo que es contextualmente malo. Creo que si estuviera trabajando en Bloomberg en su terminal de próxima generación, donde los tiempos de actualización en milisegundos importan mucho, ya sabes, algo así, donde realmente te importa mucho. O tal vez, no sé. Estoy seguro de que hay muchos de estos casos extremos donde puede que no te beneficie, pero siempre tienes... Creo que una de las ventajas de React es que tienes muchas formas de optar por no utilizarlo. Por ejemplo, con Canvas, React y Canvas no son las cosas más fáciles de integrar. Entonces, si estás haciendo renderizado en Canvas, muchas veces simplemente optarás por no utilizar el ciclo de renderizado de React obteniendo una referencia y realizando mucha lógica imperativa allí. Creo que esa es un poco la belleza de React, que puedes optar por no utilizar su modelo de renderizado en muchos casos en los que normalmente podrías decir que es una mala decisión. Sí, úsalo donde lo necesites y opta por no utilizarlo donde no lo necesites. E incluso, como hemos visto esta mañana en la charla de Misko, puedes simplemente optimizarlo 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. ¿También está disponible la charla sobre Why Not App Router? Lo está preguntando para un amigo. Lo siento, ¿qué? La charla que mencionaste al principio, Why Not App Router. Sí.

AppRouter y Reacciones

Short description:

AppRouter existe en mi cabeza. Creo que es genial y divertido que hayamos puesto una diapositiva para burlarnos de Lee. Las reacciones de la gente hacia AppRouter son interesantes de ver en Twitter. Personalmente, me encanta e incluso di una masterclass sobre ello.

¿Qué hay de eso? ¿Realmente existe? Existe en mi cabeza. Quiero decir, creo que AppRouter es genial. Me parece divertido que estuviéramos hablando en contra de Lee, por eso pusimos la diapositiva ahí, solo para molestarlo un poco. Pero sí, no creo que tengamos ninguna objeción real más allá de que me parece gracioso cuánta gente lo odia. También me parece interesante ver cómo la gente tanto a favor como en contra gradualmente pierde la cabeza en Twitter, discutiendo 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.

React's Scope and Freedom of Choice

Short description:

Pregunta de Jay: ¿Cuál es el alcance de React en el futuro? Si se le diera la libertad de elegir, el orador se quedaría con React debido a su utilidad en varios casos de uso y su compatibilidad con Electron y React Native. El orador consideraría minimizar el uso de Flux para las tiendas y explorar alternativas como Zustand. A pesar de ser relativamente joven, Discord ha tenido un impacto significativo. El orador menciona humorísticamente la popularidad continua de jQuery en comparación con la base de usuarios más pequeña de React.

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 explicar, ¿o es Jay remoto? ¿Jay remoto, puedes explicar? ¿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 preguntarle a los chicos de ForSale. Gracias.

Muy bien, pregunta de Anónimo. Si tuvieras la completa libertad de escribir Discord con un equipo lo suficientemente grande en cualquier framework, ¿te quedarías con React o probarías otro framework? Uf. De acuerdo. No creo que lo que cambiaría sea React, porque creo que obtenemos muchos casos de uso buenos de él, como Electron y todo eso, y luego React Native es súper útil. También hacemos mucho código nativo, como 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. ¿Es eso Zustand? No lo sé. Ese tipo de cosas. Pero aparte de eso, no creo que me quedaría con React. Creo que ese sería el que elegiría, sí. Además, Discord salió en 2015, 2014, ¿verdad? ¿Es bastante joven? Sí. No es tan antiguo. Parece que ha estado aquí desde hace siglos. Tal vez estoy equivocado. Solo inventé una fecha al azar. Nadie lo verifique. Espera, ¿qué harías tú? Si fueras React, ¿lo harías? ¿Has oído hablar de jQuery? Oye. Todavía es lo más grande que hay. Quiero decir, React es una fracción de la base de usuarios de jQuery.

Using Rust and Tori, TRPC, and GraphQL

Short description:

Uso Rust y Tori para mis proyectos. Rust se puede compilar a Wasm, lo que permite que todo esté en Rust. Se hizo una pregunta sobre TRPC y el orador compartió su experiencia positiva con él. También mencionó haber inventado una herramienta similar llamada MagicAPI. A pesar de que le gusta TRPC, el orador prefiere GraphQL.

Oh no, ¿sabes qué hago? Uso Rust. Y uso Tori. Bueno, eso es cierto, sí. Luego todavía tienes que tener una capa de interfaz de usuario. Sí, eso es cierto. Eso es verdad. Vaya. Correcto. Rust. Compílalo a Wasm. Y luego tienes todo en Rust. Suena como un desarrollo de security impulsado por un trabajo adecuado. Exactamente. Exactamente.

Aquí hay una pregunta de no-Teo. No-Teo, así que Teo no está haciendo esta pregunta. Creo que Teo está remoto. ¿Cuál es tu opinión sobre TRPC? Oh. Bueno, lo usé hace mucho tiempo para un proyecto y fue súper, súper increíble. Fue muy fácil de usar. Soy muy malo hablando de los aspectos técnicos, así que él fue quien me presentó a TRPC para ese proyecto si quieres hablar de ello un poco. Dato curioso, inventé TRPC antes de que fuera inventado. Está en mi GitHub. Se llama MagicAPI. Auto-promoción descarada. Quiero decir, es horrible. No lo uses. Pero, no, me encanta TRPC. Prefiero GraphQL. Soy un gran fan de GraphQL.

TRPC, Implementando React y Palabras Finales

Short description:

TRPC puede ser una gran solución para resolver problemas en escalas más pequeñas, pero puede que no sea adecuado para grandes empresas con miles de microservicios. La implementación de React en sistemas ya construidos, como sistemas de gestión de servicios de TI, es altamente contextual y depende de factores como los procesos de la empresa y el alcance del proyecto. El enfoque adoptado puede variar considerablemente, desde discusiones de un año hasta migraciones simples. ¡Gracias por asistir a esta charla y disfruta tu tiempo en Ámsterdam!

Pero creo que TRPC resuelve muchos problemas, especialmente en escalas más pequeñas. Creo... No puedo imaginar usar TRPC en una empresa del tamaño de Netflix, pero creo que TRPC es genial. Sí, incluso para muchas empresas. Es como, ya sabes, cuando tienes mil microservicios y estás tratando de agruparlos 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 debemos 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 evasión, pero es muy contextual y, como tu empresa opera de manera diferente. Quiero decir, como, ya sabes, el enfoque que tomé en Netflix, por ejemplo, fue, quiero decir, duró un año y aún era una discusión en curso cuando me fui. Y hasta el día de hoy, ahora un año después, todavía hay alguna discusión en curso sobre, ¿cuál es lo próximo? Así que no es una discusión fácil y cada empresa navegará esto de manera diferente. Pero similar, como en mi empresa actual, hemos realizado migraciones de vista areact que fueron tan simples como ir a un grupo de personas y preguntar, oye, ¿estamos todos de acuerdo con esto, verdad? Así que va a variar mucho según, ya sabes, cuál es 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 comentario final? Ninguno. Fue genial hacer esta charla. Muchas gracias por invitarnos. Muy bien. Disfruta el resto de tu tiempo en Ámsterdam. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn