La Era de React Universal: ¿Cuál es el Truco?

Amigos, muchas gracias por venir aquí. Ambos estamos increíblemente emocionados de estar con ustedes. Vamos a hablar sobre la era de React universal, que creemos que es este próximo cambio de paradigma de React. Y estamos increíblemente emocionados de hablar sobre ello. Vamos a ver lo bueno, lo malo, lo feo, y con suerte un poco hacia el futuro.

Como mencionó Antonio, mi nombre es Mo. Dirijo el equipo móvil en Theodo. Siempre me ha encantado construir aplicaciones. Construí mi primera aplicación cuando tenía 13 años. Así que comencé con iOS nativo, me pasé al mundo web con React, y luego volví a nativo con React Native. Así que creo que React universal encapsula todas las cosas que he hecho en mi viaje y estoy súper emocionado por ello.

Sí, así que Mo y yo nos conocimos en las muchas conferencias a las que hemos asistido y hablado durante los últimos años. Y nos dimos cuenta de que ambos estábamos hablando de temas muy adyacentes. Mo estaba hablando sobre compartir código entre React y React Native. Yo estaba hablando sobre construir para múltiples dispositivos. Y entonces decidimos, unamos esfuerzos y hablemos sobre React universal. A diferencia de Mo, no sé qué estaba haciendo cuando tenía 13 años, probablemente jugando, no sé, Pokémon o algo así. Pero comencé como desarrollador web hace ocho años y era un desarrollador de React. Y luego me pasé a React Native. Y actualmente soy defensor de desarrolladores de React Native en Amazon App Store, que es la tienda de aplicaciones que funciona en nuestros dispositivos. Así que los tipos de aplicaciones con las que trabajo funcionan en teléfonos, tabletas, automóviles, web, TV. Y React universal me ayuda a mí y a nuestros desarrolladores a navegar por ese mundo fragmentado de todos los dispositivos que tenemos que apuntar.

Entonces, la primera pregunta en la mente de todos debe ser, ¿qué es React Universal? Entonces, React Universal son aplicaciones multiplataforma de React y React Native. En mi opinión, lo que significa es un principio de aprender una vez, escribir una vez y ejecutar en cualquier lugar. Y esa es mi respuesta. Pero hace un mes en React Native London, Mo nos hizo esa pregunta a un panel. Así que quiero devolvértela, Mo. ¿Qué significa para ti? Porque para mí, es aprender una vez, escribir una vez, ejecutar en cualquier lugar. Pero, ¿y para ti?

Voy a tomar un enfoque ligeramente diferente a esto, porque quiero hablar sobre lo que esto nos da el potencial de tener. Creo que el poder de las aplicaciones universales es que iguala las condiciones para equipos pequeños y desarrolladores independientes para realmente enfrentarse a los grandes gigantes existentes que están en la industria. Un ejemplo principal de esto es BlueSky. ¿Cuántos de ustedes han oído hablar de BlueSky recientemente? Exactamente, ¿verdad? Entonces, BlueSky es un pequeño equipo de cuatro o cinco desarrolladores que están enfrentándose a X, Twitter, como sea que se llame estos días, y están enfrentándose a algunas de las personas más ricas del mundo para construir su propia red social, lo cual creo que es increíblemente poderoso. Y realmente, la columna vertebral de esto es React Universal, lo cual es realmente genial. Y así, en su núcleo, comienza con una única base de código. Usas una base de código para dirigirte a múltiples plataformas, ya sea web, móvil, TV, AR, VR. Realmente, el mundo es tu ostra. Y utiliza React y los principios web con los que todos estamos familiarizados y los pone en tecnologías nativas. Pero lo hace de una manera que no compromete la naturaleza nativa de cada una de esas plataformas. Así que estas no son algún tipo de aplicaciones de vista web de mala calidad a las que estás acostumbrado que realmente no se sienten como una aplicación nativa. Son experiencias verdaderamente nativas para cada una de las plataformas a las que te diriges. Y lo que esto significa en principio es que tú, como probablemente un grupo de desarrolladores web principalmente, puedes usar esa tecnología web familiar, JavaScript, CSS styling, mi favorito storybook, para el desarrollo de aplicaciones, desarrollo de TV, desarrollo de VR, sin tener que aprender nuevas tecnologías y lenguajes. Y el beneficio adicional de esto es que te ayuda a dirigirte a esa compleja fragmentación del paisaje de dispositivos. No necesitas un equipo por plataforma o por dispositivo. Y esto te ayuda a ahorrar costos en reconstruir lo mismo múltiples veces, lo que significa más dinero para el desarrollo de características, para mejorar el producto real, y realmente para mantener felices a tus PMs.

Entonces, Mo, dijiste que desarrollaste aplicaciones desde que tenías 13 años. ¿Fue eso hace 10, 20, 30 años? ¿Por qué no nos das un poco de una lección de historia? Mira, sé que estoy perdiendo el cabello y todo, pero no tienes que hacerme sentir como un abuelo calvo. Pensé que deberías colorearlo. Está bien. De acuerdo. Eso es lo mío. Desafortunadamente, el color no se aplica a la calvicie, pero aquí estamos. Así que lección de historia.

En 2013, React sale. Y React solo puede dirigirse a la web en ese momento. Y así, en los siguientes dos años, evoluciona, y realmente se convierte en este nuevo paradigma y esta nueva forma de construir aplicaciones web. Este enfoque declarativo basado en componentes simplemente toma al mundo de la interfaz de usuario por sorpresa.

Y luego, en 2015, tenemos este momento en el que React y React DOM se dividen en paquetes separados. Y esto abre una nueva puerta de posibilidades donde React se convierte en esta forma agnóstica de definir interfaces de usuario y diseños, pero puedes emparejarlo con cualquier renderizador para cualquier plataforma. Y ahí es donde nace React Native. Comienza como una forma de construir aplicaciones iOS de manera declarativa, lo cual era inaudito en el mundo móvil. Estamos lidiando con días imperativos en móviles. Y luego, obviamente, también puedes dirigirte a Android muy poco después. Y así, estos ecosistemas comienzan a desarrollarse por su cuenta. React tiene su propia comunidad, su propio conjunto de herramientas, su propio ecosistema, y lo mismo ocurre con React Native. Y estos están funcionando en paralelo porque ambos son realmente React. Pero en su núcleo, hay casi esta desconexión. Y así, algunas personas dentro de este ecosistema tuvieron la realización de que estas cosas en realidad no están tan separadas entre sí.

Y naturalmente, como tenemos muchos desarrolladores de React en la sala, solo una muestra de manos, ¿cuántos de ustedes son solo desarrolladores web de React? Bien, así que solo diré para todos, alrededor del 50% si estás remoto, si no más. Creo que ya que tenemos muchos desarrolladores de React en la sala, dejaré que Anisha nos dé un rápido curso intensivo sobre la diferencia entre React y React Native. Y la razón por la que estamos haciendo esto es porque para entender cómo funciona React universal, necesitamos entender las diferencias que está tratando de cerrar. Así que, primero, en realidad no es tan diferente. React Native utiliza la misma sintaxis JSX que React, por lo que es realmente fácil hacer la transición. Tienes los mismos hooks, tienes la misma sintaxis. La principal diferencia está en los componentes integrados. Así que React Native utiliza vistas, texto, botones, en lugar de elementos HTML. Y lo que es realmente genial es que estos vienen directamente de React Native. Se importan de React Native, por lo que no tienes que crear esos componentes tú mismo. Y luego hay algunas otras diferencias, como los métodos. Así que en React, tendrás tu propio click en tu botón, y en React Native, tendrás tu propio press. Con el estilo, de nuevo, bastante similar. Ambos permiten el estilo en línea, ambos soportan la creación de objetos de estilo reutilizables. Las diferencias son que React utiliza CSS o CSS en JS, mientras que React Native utiliza un subconjunto de las propiedades CSS con nombres en camel case.

Entonces, cuando decimos subconjunto, nos referimos a cosas como que la cuadrícula no es compatible porque no se mapean bien a esos diseños nativos. Y React Native no usa nombres de clase. Esos estilos se aplican directamente a los componentes. Creo que la mayor diferencia fundamental entre React y React Native es la arquitectura y el renderizado. Así que ambos tienen exactamente el mismo mecanismo de DOM virtual, donde el árbol antiguo se compara con el actualizado para determinar qué necesita cambiarse. Pero la diferencia es que en React, después de que se realiza la comparación, los cambios se cometen al DOM real para agregar lo nuevo y cambiar o eliminar lo que se ha actualizado. React luego usa las APIs del DOM del navegador para manipular la interfaz de usuario en el navegador web. Sin embargo, React Native tiene una capa intermedia llamada fabric, que maneja la conversión de esos elementos del DOM virtual en componentes para renderizar. Así que renderizará los elementos del DOM virtual en los elementos nativos reales. Así que, por ejemplo, tu pestaña se convertirá en tu pestaña de Android, tu pestaña se convertirá en tu pestaña de iOS.

Y luego, finalmente, bibliotecas y herramientas. Así que muchas cosas, de nuevo, lo mismo, ¿verdad? Así que cuando se trata de gestión de estado, cuando se trata de obtención de datos, bibliotecas como MobX, Redux, Axios, Fetch, todas funcionan exactamente igual. La diferencia está en la navegación y en las bibliotecas de interfaz de usuario y en las pruebas unitarias. Así que para la navegación, en React, tenemos React Router. En React Native, tenemos React Navigation. Y esto se debe a que la forma en que funciona la navegación en la web y en el móvil es bastante diferente, ¿verdad? En la web, tendrás tu navegación basada en URL. Cuando tienes tu teléfono, es más una navegación basada en pilas. Lo piensas como cuando cargas una nueva pantalla, se apila sobre la pantalla anterior, y así es como avanzas con tu navegación. Con las bibliotecas de interfaz de usuario, es diferente porque vimos que hay diferentes elementos, hay diferentes estilos. Así que tendrás bibliotecas de interfaz de usuario como material en el mundo web. Los equivalentes son como React Native Paper en el mundo de React Native. Y lo mismo para las pruebas unitarias. Debido a esos métodos como onClick versus onPress, en React, tenemos React Testing Library. En React Native, tenemos React Native Testing Library, que se basa en los mismos conceptos que React Testing Library. Y así, esa pieza de la biblioteca es muy interesante porque, como ves, muchas de esas bibliotecas son realmente compartidas. Y entonces la pregunta se convierte, para las que no se comparten en este momento, ¿hay quizás una manera en la que podamos comenzar a cerrar la brecha y crear las llamadas bibliotecas universales? Y así se formó esta visión de React Once, Run Anywhere. Y la comunidad ha querido compartir nativo y web desde el principio. Así que haré mi propia lección de historia ahora. En 2016, React Native Web fue creado por Nicholas Gallagher. Y React Native Web es quizás actualmente la implementación más directa de los principios universales de React.

Así que implementa componentes y APIs de React Native de manera interoperable con React DOM. Y esto en realidad terminó impulsando una gran parte de la plataforma web de Twitter.

Luego, en 2017, vimos ReactXP, que también fue un pionero temprano en React universal. Esta biblioteca de componentes agnóstica a la plataforma te permitía compartir tus definiciones de vista, estilos, animaciones a través de múltiples objetivos. Y esto específicamente fue construido por Microsoft con el propósito de compartir código en Skype.

Y luego, el año pasado, vimos XProBooter. Y siento que XProBooter realmente completó la visión de XPro de React universal al proporcionar este mecanismo de enrutamiento que funciona de manera idéntica en plataformas web y nativas y nos permitió navegar entre pantallas en nuestra aplicación y web usando los mismos componentes, lo cual es realmente poderoso, ¿verdad? Vimos esa tabla. Había una gran brecha en la navegación y la UI. Y siento que XPro ha llenado esto y realmente ha tratado de completar esa historia de React universal. Y así, estas bibliotecas han impulsado diferentes niveles de intercambio de código a lo largo de los años. Voy a volver a 2018. Un colega mío, Ben Ellervy, dio una charla en React Amsterdam.

Ahora, levanten la mano, ¿quién ha estado realmente en React Amsterdam? Solo como tres o cuatro personas. Bien. React Amsterdam, para aquellos de ustedes que no lo saben, es el predecesor de React Summit. Así que está organizado por la encantadora gente de Git Nation. Honestamente, organizan tantas conferencias. ¿Podemos darles un gran aplauso por todo el buen trabajo que hacen por esta comunidad? Y así, en esta charla, Ben habla sobre un caso de compartir código entre React y React Native. Y él analiza qué no compartir. Y así, en ese entonces, React universal estaba realmente en la vanguardia. Y así, evaluaron y decidieron, en realidad, ¿saben qué? No vamos a compartir ninguna de nuestra capa de vista, ninguno de nuestros componentes, ninguna de nuestra navegación. Vamos a compartir lo que es básico y realmente solo JavaScript. Compartiremos cosas como nuestra configuración de la aplicación, nuestra gestión de estado, tal vez algunas llamadas a APIs y servicios. Pero en cada una de las aplicaciones para web y móvil, lo que vamos a hacer es separar los componentes y las navegaciones e implementarlos específicamente para esas plataformas.

A diferencia del mundo actual, donde realmente puedes compartir casi todo. Así que todas las cosas que compartieron tal vez hace cinco años, más componentes de UI, navegación, e incluso tu empaquetado y tus procesos de construcción. Y así, si comenzamos a mirar una escala, tienes en el lado izquierdo el intercambio básico de código, que fue el ejemplo de mate.com que Ben estaba revisando. Y en el lado derecho, tienes una pila universal completa. Y lo que realmente puedes comenzar a ver es que a medida que avanzas de izquierda a derecha, maximizas el intercambio de código, reduces la duplicación y no estás reimplementando lo mismo una y otra vez para cada plataforma a costa de poder optimizar la plataforma para tus aplicaciones web o móviles.

Y lo que estamos tratando de decir aquí es que las aplicaciones universales son en realidad un espectro. No son un binario. No es que seas universal o no seas universal. Al comenzar a adoptar el intercambio de código y una mentalidad de intercambio de código, puedes comenzar a hacer tu aplicación más y más universal. Y así, naturalmente, tendrás que tomar la decisión sobre qué compensación tiene sentido para ti, llevando a la pregunta muy importante de qué deberías compartir. O parafraseando a Shakespeare, ¿compartir o no compartir? Esa es la cuestión. Así que echemos un vistazo a una típica, qué compone una típica aplicación universal de React, ¿verdad? Así que tendrás tu lógica de negocio, capas de API, configuración, hooks personalizados. Todos estos se pueden reutilizar. Y de hecho, sé que actualmente muchas personas ya los ponen en paquetes separados, pero realmente quiero entrar en la guerra de monorepo versus multi repo. Así que el estado de la aplicación, nuevamente, vimos que las bibliotecas de gestión de estado son las mismas. Así que el estado de la aplicación se puede reutilizar fácilmente en tu aplicación. La navegación, mencionamos, es donde podrías tener que comenzar a personalizar las cosas un poco porque esas rutas de navegación podrían ser diferentes entre factores de forma. Cuando llegamos a la UI, se descompone en, creo, tres cosas. Tokens de diseño, compartibles, porque son solo variables. Los componentes son, nuevamente, donde podríamos tener que tomarlo caso por caso. Y veremos un ejemplo en la siguiente diapositiva. Y luego tu diseño. Y esta es probablemente la única cosa que no querrás compartir, porque tu diseño va a verse muy diferente en cada factor de forma. Así que mencionamos componentes, ¿verdad? Así que este es Zygo. Es una biblioteca de UI para un menú contextual desarrollado por Fernando Rojo. Y esto es lo que en el lado izquierdo, en el lado derecho, no sé, realmente no puedo decir. Pero en un lado, es lo que parece en la web. Y en el otro lado es lo que parece para nativo. Y como puedes ver, como usuario, esperarías que se vea diferente en tu web y en tu móvil. Y así, ese es un ejemplo de donde, sí, no puedes tener la misma biblioteca.

Y es una biblioteca universal. Pero está optimizada por plataforma por esa razón particular de que los componentes podrían tener que ser diferentes. Lo mismo con el diseño. Esto es Amazon Prime en TV. En el lado izquierdo, puedes ver que hay este menú adicional, ¿verdad? Así que para buscar y tu cuadrícula y para guardar. Vamos a verlo en, ya sabes, un escritorio o web. Así que esta es la misma aplicación de Amazon Prime en la web. Y como puedes ver, hay, hay en esa barra de navegación. Y eso muestra que la navegación y el diseño van a ser ligeramente diferentes.

Ahora, esto es Amazon Prime en móvil. Así que ya sabes, misma aplicación, cuatro factores de forma diferentes. Va a tener que ser optimizado para el diseño para ese factor de forma. Así que hemos hablado mucho sobre lo que puedes hacer. Vamos a entrar en el cómo. Así que veamos las tecnologías actuales que nos permiten construir de manera universal hoy. Como mencionó Aneesha, React Native for Web de Nicholas Gallagher es realmente el bloque de construcción básico de todo esto. Es la capa de compatibilidad que se encuentra entre React Native y React Dom. Y así, esta es una capa de compatibilidad que envías como parte de tu aplicación. Es parte de tu paquete. Y básicamente maneja las traducciones de vistas y textos a divs y elementos P. Es realmente esa capa de compatibilidad que ajusta todo. Y lo que tienes que pensar aquí es que debido a que React Native tiene un área de superficie tan grande, puedes ver en el diagrama en el lado derecho, tienes una capa de compatibilidad realmente compleja y compleja para tomar React Native y hacerlo compatible en la web. Ahora Aneesha habló sobre algunas de las diferencias que tenemos entre plataformas web y nativas. ¿Cómo resuelve React Native web algunos de esos desafíos? Sí. Así que pensemos en lo que hablamos, esas diferencias. Así que diferentes componentes. Ahora React Native agrega este mapeo de componentes. Así que componentes como tu vista, tu texto, tu imagen en React Native se mapean a los equivalentes apropiados de HTML y CSS. Por ejemplo, tu vista se convertirá en tu div. Y luego cuando tenemos nuestra capa de renderizado, así que habrá una compatibilidad de API para la web.

Así que se proporcionan implementaciones específicas para la web de esas APIs de React Native. Y esto asegura que cosas como el manejo de gestos y otras cosas específicas de React Native funcionen de la misma manera en web y móvil. Y luego para el estilo, tenemos abstracciones de estilo. Así que hay un sistema de estilos multiplataforma similar a la hoja de estilo de React Native que convierte estilos en línea y propiedades de capa a esa capa CSS compatible con la web. Y no estamos diciendo que tengas que construir en React Native. Lo que estamos tratando de decir es que esto ha permitido estas bibliotecas universales que te permiten construir multiplataforma.

Y lo siento, Mo, ¿podrías? Así que lo que hemos visto son estas, la siguiente diapositiva, la tabla. Sí, gracias. Así que lo que hemos visto es que estas bibliotecas universales se han desarrollado. Y eso es gracias a React Native web. Así que en el espacio de navegación, vimos Experuto. Pero hay otras bibliotecas como Seleto. En el espacio de bibliotecas de UI, debido al mapeo de componentes, debido a las abstracciones de estilo, tenemos estas bibliotecas universales de React, como Tamagoyi, Gluestack, Unistyles, donde escribes componentes una vez, y luego se renderizan específicamente en React y React Native. Un espacio que todavía se está explorando, creo que es el de pruebas. Así que veremos qué sucede. Como, veamos cuál es el futuro. Pero estas son las herramientas. ¿Qué pasa con los marcos?

Así que Expo es actualmente el framework de elección para React Native. Y este año, hemos visto Expo Router V3, que siento que, como dije, realmente completa esta historia universal.

Así que el mes pasado, asistí a React Native London Con. Y hubo una masterclass realmente genial realizada por Keith. Así que este es solo el demo de esa masterclass. Así que, sí, déjame moverme aquí. Así que esto es como lo que construimos, que es una app que comparte tus rutas, tanto en web como en móvil. Así que es como puedes ver que hay una app. Y luego cuando la ejecutamos en web, esto es lo que parece. Y luego cuando ejecutamos esa misma app en móvil, así es como se ve. Así que son las mismas rutas, el mismo diseño y todo. Así que hagamos un cambio. Bienvenido React Berlin. No, se llama React Day Berlin. Lo siento. Perdóname. Pero haz el cambio inmediatamente. Se refleja en la web. Y lo mismo, de nuevo, inmediatamente se refleja en móvil. Así que puedes ver, como, eso es poderoso. Como, un comando significa que puedes ejecutar tu app con las mismas rutas, el mismo diseño, la misma navegación en ambos web y móvil. Y creo que, como, eso existió este año. Y creo que, quiero decir, estoy realmente emocionado.

Ahora, otra cosa que ves en el ecosistema que la gente hace es que realmente deciden crear frameworks específicos para cada una de las diferentes plataformas. Así que usan diferentes frameworks para cada una de las diferentes plataformas. Por ejemplo, puedes usar Next.js en la web, y puedes usar Expo para el lado nativo. Y típicamente la gente inicia esto con un monorepo. Crearán un paquete central o varios paquetes, y esto incluye toda tu lógica de aplicación. Así que incluye configuración de la app, gestión de estado, llamadas a la API, tus componentes de UI también. Así que estás compartiendo componentes de UI.

Hemos avanzado, y estamos compartiendo cada vez más. Y también una abstracción de navegación que se sitúa sobre las diferentes plataformas que tienes, y te permite hacer las mismas llamadas de navegación desde las mismas pantallas, efectivamente. Y luego esos se importan en una aplicación Next separada y una aplicación Expo separada. Y así, esas aplicaciones se encargan de manejar las llamadas de navegación, la implementación de esas navegaciones, pero también los procesos de construcción y empaquetado. Y esto es poderoso por una razón muy importante, que es si estás usando Expo router, estás usando Metro, es un empaquetador que está optimizado para nativo, por lo que no viene con cosas como SSR o buen soporte de tree shaking. Aquí realmente puedes, en el sitio web, optimizar y hacer que el rendimiento sea óptimo, porque estás usando todas las cosas y características que vienen con Next.js, lo cual creo que es poderoso. Así que esto es algo que vemos en la práctica bastante hoy en día al construir de manera universal.

Ahora hemos hablado de lo bueno, hemos hablado del estado del presente, en realidad queremos hablar de lo malo y lo feo, como dijimos.

Así que uno de los desafíos hoy en día es que las plataformas fuera del árbol tienen una gran dificultad para mantenerse en paridad con React Native Core.

Ahora solo una rápida explicación. Las plataformas fuera del árbol son las plataformas no principales en React Native. Así que típicamente React Native Core se envía con iOS y Android. Cualquiera de las otras plataformas se refiere como plataformas fuera del árbol. No son mantenidas por meta, la comunidad las mantiene.

Así que un ejemplo de ellas es React Native Windows, que es mantenido por la gente de Microsoft.

Y si ves en la parte superior, tienen 168 problemas abiertos para la paridad con React Native. Ahora, esto de ninguna manera es una acusación a la gente de Microsoft que trabaja en esto. Hacen un trabajo fenomenal. Diría que este es uno de los mejores. Solo muestra lo difícil que es mantenerse en paridad con React Native Core.

Y tengo una hipótesis de por qué es así. Si vas a la documentación de React Native y abres cualquiera de los componentes, solo elige pressable, que es tu componente interactivo típico de botón, puedes ver que hay algunos props como Android underscore disable sound o Android underscore ripple. Así que estos son parte del núcleo de React Native, pero son implementaciones muy específicas de la plataforma. Tomemos otro ejemplo, text. Hay text break strategy. También hay line break strategy iOS. Estos parecen que deberían ser solo un prop. Y creo que lo que realmente empezarás a ver es que React Native está actualmente estrechamente vinculado a las APIs de iOS y Android. Lo cual va en contra de la filosofía fundamental de React y React Native, que es que debería tener una API agnóstica de plataforma. Así que se están realizando muchos esfuerzos para limpiar esto y hacerlo más liviano para que sea más fácil para los mantenedores de plataformas fuera del árbol mantenerse en paridad.

Creo que el segundo desafío y uno importante es el rendimiento en la web. Así que el rendimiento en la web actualmente dijimos que tenemos que usar React Native web. Y si miras el tamaño del paquete de React Native web, es de unos 250 kilobytes minificado y unos 75 kilobytes gzip. Eso es enorme. Estás añadiendo esto como una capa de compatibilidad. Así que eso es porque maneja todo, desde animaciones JS hasta el estilo en tiempo de ejecución JS. Contiene un montón de cosas que realmente no quieres usar en la web.

Así que lo que esto efectivamente significa es que tú, como desarrolladores de aplicaciones, necesitarás dedicar algo de tiempo a averiguar qué quieres usar de React Native web. Tal vez eliminando algunas de las dependencias. Tal vez parcheando algo de ello. Pero puedes llegar a un buen estado con el rendimiento. Solo que requerirá trabajo. Así que es algo a considerar.

Así que hemos mirado el pasado. Miramos el presente. ¿Qué hay del futuro? Creo que el futuro de Universal React realmente está en React Strict DOM. Así que a principios de este año, Meta anunció React Strict DOM como un enfoque para el desarrollo de React multiplataforma que apunta a resolver ese problema de compartir componentes entre web y nativo. Y esto fue por Meta. No fue un esfuerzo comunitario como React Native web. Pero la diferencia fue que querían que tuviera un buen rendimiento en la web. Así que lo que hace React Strict DOM es aprovechar las APIs que tú, como desarrolladores web, estarás usando para construir aplicaciones universales. Así que con React Native web, la carga de traducir y soportar esas APIs estaba en la aplicación web. React Strict DOM toma un enfoque casi opuesto. Pone esa carga de compatibilidad y traducción de APIs en el lado móvil y utiliza esas APIs web con las que estamos familiarizados para renderizar componentes. Así que al proporcionar un subconjunto de APIs DOM, que es como esa columna que ves en el medio, ¿verdad? , tenemos esta capa que las traduce en entornos tanto web como nativos. Y esto significa que puedes escribir código una vez y ejecutarlo en todas partes con modificaciones específicas de plataforma mínimas. Así que abraza esos elementos DOM e integra estrechamente con StyleX para un estilo unificado para darnos este enfoque de escribir una vez y ejecutar en cualquier lugar. Y creo que lo que es increíble es que Meta también lo ha estado probando ellos mismos. Y actualmente se está utilizando en producción en Instagram y Facebook.

React Strict DOM realmente está haciendo de la web una prioridad de primera clase. De manera similar, la comunidad ha estado trabajando en un esfuerzo por llevar las APIs web, por lo que APIs compatibles con las especificaciones W3C y moverlas a React Native y darles soporte. Y eso es porque muchas de las APIs que puedes usar para acceder a la información del dispositivo y así sucesivamente en React Native son dirigidas por la comunidad y no están estandarizadas. Mientras que la web es muy madura en este espacio. Así que toda la idea, y esto está respaldado por la gente de Microsoft, es que podemos traer algunas de esas APIs web y facilita que los desarrolladores web puedan acceder a las mismas APIs pero con implementaciones nativas en el lado nativo.

Y creo que esto es increíblemente importante. Son dos partes del mismo rompecabezas. Y, por supuesto, React Native acaba de lanzar su nueva arquitectura en la que han estado trabajando creo que durante seis años. Y parte de eso, que está subestimado y no se habla tanto, es este nuevo bucle de eventos. Así que el bucle de eventos en React Native no estaba estandarizado. No se comportaba de la misma manera que en la web. Así que si usabas algo como un efecto de diseño, en realidad se comportaría de manera bastante diferente en nativo que en la web. Y así este nuevo bucle de eventos básicamente corrige eso y lo estandariza y lo alinea con la web. Y ves lo que es esta convergencia en el lado del renderizado, en el lado de las APIs, e incluso en los internos de React Native, se está acercando cada vez más a la web. Hay una convergencia. Esas líneas paralelas y esos ecosistemas se están reuniendo y convergiendo. Y así las cosas se están volviendo más unificadas y, me atrevo a decir, se están volviendo más universales.

Así que lo que creo que realmente estamos moviendo es a esta era de React One que se ejecuta en todas partes. Y esto es porque React no es solo web. Y React Native no es solo móvil. Más bien, React es un framework de escritorio. React se puede usar para construir televisores. Aplicaciones de TV, no televisores. Tal vez televisores. No lo sé. React se puede usar para construir aplicaciones de AR y VR. Y sí, React también se puede usar para la web. Y también se puede usar para móvil. En última instancia... Lo que estamos tratando de decir es que React es universal.

Así que si estás interesado en leer un poco más sobre esto, hay un código QR allí. Yo y un colega mío en realidad escribimos un folleto sobre aplicaciones universales primero, que es la forma en que arquitectas tu aplicación desde cero para que sea universal. Así que esto es solo un PDF. Puedes escanearlo. Y con suerte eso es algo de lectura. Y estoy más que feliz de charlar contigo sobre eso más tarde.

Muchas gracias, chicos. Realmente esperamos que ustedes comiencen a usar aplicaciones universales de React. Y estas son nuestras redes sociales. Así que si quieres seguirnos o hacer más preguntas, Mo y yo estamos aquí. Gracias. Muchas gracias.

Antes de hacer eso, amigos, ¿cómo se sienten? ¿Buena charla? ¿Buena charla? Estamos rebotando el uno del otro. Y fuiste un poco malo con el tema de la edad allí. Vamos. Es realmente grosero. Vamos. Sí. No hay edadismo aquí. Es una broma interna. Permítanme aclarar. Es una broma interna. Estamos bromeando. Estamos bromeando. Pero muy emocionado de entrar en estas preguntas.

Y voy a saltar directamente a la pregunta más votada, que es sobre React. Rara vez se usa solo como React. Pero se usa en un framework, Next.js, Remix, y mil otros sabores. Entonces, ¿cómo haces que una aplicación Next o una aplicación Remix sea universal sin reescribir desde cero? Así que hay algunos esfuerzos aquí que pueden ayudarte. La primera cosa que puedo mencionar es expodom. Así que Expo ha estado trabajando en un esfuerzo donde casi con vistas web puedes tomar el código web existente y comenzar a llevarlo al nativo. No van a ser componentes nativos. Pero es casi un puente y un camino hacia la migración de web a nativo. Creo que realmente tu mejor amigo aquí es la historia del monorepo, o encontrar una manera de abstraer y empaquetar muchas de estas dependencias. Así que React strict DOM también está entrando en juego, lo que significa que puedes tomar mucho de ese código web que tienes en Next.js o Remix y así sucesivamente, y ponerlos y adaptarlos con React strict DOM muy pronto, y luego ponerlos en paquetes que son importados por, digamos, tu aplicación Next, y luego también por tu aplicación nativa. Y así creo que hay muchas cosas en el horizonte.

Y la última, me atrevo a decir, es el mundo espeluznante de la IA generativa. Como, he hecho algunos experimentos. Puedes usar genAI muy bien para convertir HTML a código nativo de React con vistas y texto. Lo hace fenomenalmente. Como, llega al 90% del camino, y luego es solo un trabajo manual. Así que usa LLMs donde tenga sentido, y creo que este es uno de los lugares donde lo hace.

Eso tiene sentido. La siguiente pregunta es sobre el impacto en el rendimiento. Lo siento, pensé que la accesibilidad estaba aquí, pero esta simplemente saltó. Entonces, ¿cuál es el impacto en el rendimiento de tomar un enfoque universal de React? ¿Cómo ayuda al rendimiento, perjudica el rendimiento, especialmente en cada plataforma individual? Sí, creo que intentamos tocarlo un poco. Pero sí, con React Native Web, es un gran paquete, y esa presión está en la web para traducir todo. Pero creo que con React strict DOM, está construido pensando en el rendimiento. Así que no se ha construido solo para mejorar el rendimiento en la web. Se ha construido para mejorar el rendimiento en general. Así que si miras la documentación de React strict DOM, uno de los principios es que estamos construyendo React strict DOM para mejorar el rendimiento, para mejorar la forma en que construimos en React y React Native funciona.

Genial. Solo para añadir a eso también, parte de lo que necesitarás tener en cuenta son las dependencias que usas. Crea diferentes dependencias e implementaciones de componentes como Anisha mostró con Ziggo que están optimizadas para la web y no cargan un montón de cosas que no necesitas, y funcionan bien en nativo también. Y tienes que elegir las dependencias y a veces crear abstracciones sobre las dependencias. Y de esa manera no inflas el tamaño de tu paquete y no perjudicas el rendimiento web.

En nativo, no tiene tanto efecto porque son las mismas bibliotecas de React Native que usarías de todos modos. Bien. La siguiente pregunta es sobre accesibilidad. Entonces, hacer aplicaciones accesibles en la web a menudo requiere usar APIs muy, muy específicas. Y cuando tienes esta abstracción multiplataforma, ¿puedes alcanzar el mismo nivel de calidad en términos de rendimiento? Ya hablamos sobre el rendimiento, pero y la accesibilidad. Ese fue uno de los enfoques principales de React Native Web. Así que una de las cosas que realmente querían lograr como objetivo era cubrir toda el área de especificaciones de accesibilidad web que tienes. Y así obtienes acceso cuando usas React Native Web a todo el mismo tipo de etiquetas de accesibilidad equivalentes o las mismas que usarías con cualquier aplicación de React. Y creo que es lo mismo con React Strict DOM, como, sus principios eran, sí, rendimiento accesibilidad y en el diseño, como, la accesibilidad es lo primero que están tratando de asegurar que sea lo mismo. Sí. Totalmente.