¿Deberías usar React en 2023?

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Spanish audio is available in the player settings
Bookmark
Rate this content

Los meta marcos están 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é marco elegir. Está hablando sobre las ventajas de usar React, centrándose principalmente en los aspectos positivos pero también ofreciendo pensamientos constructivos sobre por qué podrías no querer usarlo. ¿Deberías usar React en 2023?

This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.

FAQ

La respuesta a si debes usar React en 2023 depende de tus necesidades específicas y del contexto de tu proyecto. Aunque React sigue siendo una opción popular y potente, es importante evaluar si se ajusta a los requisitos y objetivos particulares de tu desarrollo.

React es beneficioso en proyectos grandes debido a su familiaridad en la industria, lo que facilita la contratación y la incorporación de nuevos desarrolladores. Además, cuenta con una amplia comunidad que ha resuelto la mayoría de los problemas comunes, y existen muchos recursos educativos y herramientas disponibles.

Frameworks como Next.js y Remix mejoran la experiencia de desarrollo en React al proporcionar configuraciones predeterminadas sensatas, funcionalidad extendida como renderizado en el servidor, y división automática de código, lo que optimiza tanto el desarrollo como el rendimiento de las aplicaciones.

Sí, React es muy adecuado para desarrollar interfaces de usuario complejas debido a la gran cantidad de componentes disponibles y su capacidad para integrarse con sistemas de gestión de estado y otras herramientas, facilitando la creación de interfaces ricas y dinámicas.

La familiaridad con React puede aumentar significativamente la eficiencia del desarrollo, ya que los desarrolladores con experiencia en React pueden incorporarse más rápidamente a nuevos proyectos y contribuir de manera efectiva sin un largo período de aprendizaje.

Al decidir si usar React, considera la familiaridad del equipo con el framework, los recursos y herramientas disponibles, el rendimiento necesario para la aplicación y si las características de React, como el Suspense o los Componentes del Servidor, pueden beneficiar tu proyecto.

React Native permite compartir código entre plataformas de escritorio y móviles, utilizando React. Esto es especialmente útil para desarrollos que buscan mantener consistencia y eficiencia al trabajar sobre múltiples plataformas con un único código base.

Tru Narla
Tru Narla
Jordan Gensler
Jordan Gensler
31 min
02 Jun, 2023

Comments

Sign in or register to post your comment.
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 fuera de la caja 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 que considerar los compromisos. React ofrece una forma estandarizada de trabajar y una fácil incorporación.
Available in English: Should You Use React in 2023?

1. Introducción a React

Short description:

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

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.

2. ¿Deberías usar React en 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 genial. 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 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.

3. Beneficios de React y Recursos Disponibles

Short description:

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

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.

4. Integraciones del Ecosistema React

Short description:

Existen numerosas integraciones de terceros disponibles en el ecosistema React, incluyendo bibliotecas de clientes GraphQL como Relay. Muchos proveedores de análisis también ofrecen enlaces e integraciones de React, y hay una amplia gama de componentes de interfaz de usuario disponibles. Empresas como Qlrk proporcionan servicios de Auth y una interfaz de usuario de Auth completa, facilitando mucho 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 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.

5. Rendimiento e Integración de React

Short description:

React tiene un buen rendimiento de fábrica y es adecuado para la mayoría de las aplicaciones. Los marcos de trabajo como Next.js y Remix proporcionan división automática de código y renderización del 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 los Componentes del Servidor de React ofrecen más formas de ajustar el rendimiento. Otras bibliotecas como Quick y SolidJS pueden integrarse con React para componentes críticos de rendimiento. La naturaleza basada en componentes de React permite una fácil integración entre marcos de trabajo.

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í.

6. React Native y Construcción de Productos

Short description:

React Native es súper ú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 extendido al espacio de las aplicaciones móviles es beneficioso. Missyn también considera React Native para sus productos. React es una gran elección, y está bien no usar todas las características. Enfócate en construir tu producto y no te distraigas con la tecnología brillante.

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.

7. Elegir el Marco Correcto

Short description:

React es una buena elección, pero no es la única. Hay muchos desarrolladores de React, pero también hay muchos de Vue, de Svelte, de Solid. Hoy en día, cuando se trata de rendimiento, parece que es una apuesta segura que las nuevas bibliotecas superan 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í 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. Tal vez la familiaridad es lo más importante en tu empresa, o tal vez el rendimiento es realmente crítico. Es realmente subjetivo basado en dónde estás tomando esta decisión. Permíteme darte un ejemplo de cómo la importancia puede impactar estas decisiones. Antes de unirme a Misson Labs, trabajé en Netflix en nuestra aplicación de TV, y uno de los mayores comentarios 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 usando Svelte y vimos mejoras significativas en el rendimiento y la memoria.

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.

8. Compensaciones en la Migración de React a Svelte

Short description:

Al considerar una migración de React a Svelte, hay que considerar las compensaciones. Perder el acceso a los paquetes de la comunidad y la incorporación de desarrolladores de React a 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 su proyecto. El uso de datos para tomar decisiones y la evaluación de diferentes soluciones pueden ayudar a consolidar su elecció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.

9. Reflexiones Finales sobre React

Short description:

React es genial. Tiene excelentes recursos, paquetes y una comunidad de apoyo. Al tomar decisiones, considera el peso que llevan y concéntrate en lo que estás construyendo. Evita el desarrollo impulsado por el FOMO y no te sientas presionado a adoptar nuevas tecnologías solo porque otros las están utilizando. Gracias a todos por asistir a esta masterclass sobre la elección de React. Es controvertido, pero está claro que React tiene muchas ventajas.

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.

10. React, Incorporación y Elección de Frameworks

Short description:

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

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.

11. Consideraciones Contextuales para Elegir React

Short description:

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

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.

QnA

La Adecuación Contextual de React y la Opción de No Usarlo

Short description:

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

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í.

AppRouter y Reacciones

Short description:

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

¿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.

Alcance de React y Libertad de Elección

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 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.

Uso de Rust y Tori, TRPC y GraphQL

Short description:

Utilizo 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 mencionaron la invención de una herramienta similar llamada MagicAPI. A pesar de que le gusta TRPC, el orador prefiere GraphQL.

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.

TRPC, Implementación de React y Palabras Finales

Short description:

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

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.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Documentación Full Stack
JSNation 2022JSNation 2022
28 min
Documentación Full Stack
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.