React Strict Dom: React multiplataforma basado en la web

Hoy voy a hablar sobre React multiplataforma y específicamente, una forma de usar React donde las APIs web describen no solo aplicaciones web, sino también aplicaciones nativas. La meta, la biblioteca detrás de este enfoque se llama ReactStrict DOM. En la primera parte de esta charla, voy a argumentar que aunque React para web y nativo ha sido un éxito increíble, también se ha visto limitado de algunas maneras. Pero al unificar lo mejor de React en la web y nativo, podemos desbloquear nuevo valor, nuevas posibilidades.

Y en la segunda mitad, voy a compartir el impacto que React multiplataforma está teniendo en meta y cómo encaja en un futuro donde la ingeniería de software multiplataforma está cambiando rápidamente. Así que quiero comenzar con un poco de contexto para que puedan ver de dónde vengo. El modelo de componentes declarativos de React ha cambiado cómo construimos UIs. Han pasado 15 años desde el lanzamiento de React y probablemente sea la biblioteca de UI más popular del mundo. Pero la pila tecnológica de React sigue siendo notablemente fragmentada, tanto dentro de la comunidad web como entre las comunidades web y nativas.

Lo primero que tienes que hacer con React es elegir qué plataforma apuntar, y luego aprender un conjunto específico de APIs para esa plataforma. Y esta fragmentación conduce a ineficiencias ocultas y a menudo nos obliga a tomar decisiones difíciles. En la web, React DOM ofrece a los desarrolladores mucha libertad, pero antes de que puedas escribir tu primera línea de código de UI, se te requiere tomar varias decisiones fundamentales que definen el proyecto. Lo más notable para la UI es la elección de cómo estilizar los elementos. Podrías usar módulos CSS, CSS de utilidad, CSS en JS. Hay muchas opciones, y cada proyecto es el potencial para un nuevo debate.

React en la web podría ser la única biblioteca de UI significativa que queda sin un sistema de estilo nativo de componentes incorporado. Y el resultado son inconsistencias significativas entre las bases de código y una falta de código de UI verdaderamente portátil. Así que, la flexibilidad de React en la web se ha convertido en una espada de doble filo que ha aumentado la fragmentación y elevado la barrera de entrada para los recién llegados. Y si tu producto tiene éxito, y quieres ir a nativo, te encuentras con otra bifurcación en el camino. React Native es una API diferente, y tu código web y conocimiento no se transfieren tan fácilmente. Necesitas aprender nuevos elementos, nuevos estilos, nuevos paradigmas, y más a menudo que no, las aplicaciones de React Native se reconstruyen desde cero.

Y esto no es solo un problema de web a nativo, porque muchos desarrolladores de React comienzan primero con React Native y enfrentan desafíos similares cuando se mueven a la web. Y eso es porque no hay una forma común de describir y construir aplicaciones de React, incluso en una sola plataforma. Y esta fragmentación técnica ha sido durante mucho tiempo un impuesto para los desarrolladores de React y una fuente de fragmentación comunitaria. También está claro que esta fragmentación se está convirtiendo en un obstáculo significativo para nuestra capacidad de aprovechar mejor las tecnologías emergentes como LLMs en la ingeniería de UI. Hacer un trabajo similar más de una vez, a menudo con equipos y bases de código separadas, está correlacionado con un tiempo de comercialización más lento, mayor inconsistencia del producto, menor eficiencia de ingeniería, y ahora un uso excesivo de tokens de LLM y sus correspondientes costos de cómputo.

Así que, esto ya no es simplemente un problema técnico, sino también un problema de producto y negocio. Pero, ¿y si pudiéramos unificar y estandarizar estos diferentes mundos de React? Solo una forma de usar React para construir UI en todas las plataformas. No más bifurcaciones en el camino, no más elegir entre una plataforma y otra, y no más duplicación de tareas comunes que son universales para el desarrollo de UI. Estas fueron mis motivaciones para crear React Strict DOM para unificar la forma en que describimos la UI con React. No es un reemplazo para React DOM o para React Native. En cambio, está construido sobre ellos. Y nos permite desarrollar una visión de producto consistente a través de plataformas, mientras seguimos ofreciendo experiencias nativas de plataforma.

Pero para entender cómo y por qué estamos teniendo éxito con React Strict DOM en Meta, primero quiero hablar sobre algunas otras ideas que probamos y por qué no cumplieron. Hay varios enfoques potenciales para React multiplataforma, y cada uno nos enseña algo importante sobre lo que funciona y lo que no. Lo primero que podemos considerar es usar los componentes y APIs de React Native para construir aplicaciones multiplataforma, incluyendo para la web. React Native para la web ya existe, y ha estado presente casi tanto tiempo como React Native en sí. Implementa muchos de los componentes y APIs de React para la web, y es parte de Expo, el marco predeterminado de React Native. Pero no es la solución adecuada para este problema. Tres cosas lo hacen poco práctico. La primera, ejecutar el código existente de React Native en la web no produce las experiencias accesibles y responsivas que queremos. No sin una reelaboración sustancial del código nativo original. Segundo, la mayoría del código de React que existe ya está escrito para la web. Entonces, adoptar React Native para esta tarea significaría pedir a los ingenieros de React que cambien a una API menos familiar. Y la tercera es que la API de componentes de React Native no ha evolucionado mucho en la última década, y nunca se convirtió en una opción común entre los desarrolladores web.

Pero lo que funciona realmente bien con React Native es su sistema de estilos. Eso ha permitido un ecosistema de componentes portátiles y componibles que simplemente funcionan juntos de una manera que nunca ha sido cierta para React en la web. Así que creo que eso es algo que vale la pena mantener. Otro enfoque es construir nuevos componentes de UI multiplataforma, diferentes tanto de React DOM como de React Native, donde los detalles de implementación para cada plataforma son diferentes. Por ejemplo, podríamos comenzar reemplazando div con una nueva abstracción de flex box multiplataforma como VStack. Y aunque esta es una opción para aplicaciones individuales que buscan usar abstracciones de alto nivel, realmente no funciona como una capa fundamental, y en Meta, fue demasiado problemático para las aplicaciones existentes. Porque tuvimos que diseñar, construir e introducir abstracciones significativamente diferentes y hacer cambios importantes en el código web existente, ambos de los cuales aumentaron dramáticamente las regresiones visuales.

Así que, con este enfoque, la sobrecarga de migración es alta y el valor del intercambio de código sigue siendo distante. Entonces, ¿cómo podemos encontrar una manera de minimizar los costos de migración mientras aún obtenemos el valor del intercambio de código? En lugar de seguir un enfoque que requiera reescribir el código, podemos revisar una idea que a menudo se descarta por ser poco realista. Y eso es usar nuestro código web existente para construir experiencias nativas. Porque nuestro código web ya describe cómo queremos que funcione una interfaz multimodal accesible y responsiva. Así que debemos poder renderizar nuestro código web en nativo tal como está con cambios mínimos. Y debemos poder migrar componentes existentes de una manera que sea segura, confiable y rápida, tomando minutos en lugar de semanas.

Y aunque queremos escribir una vez y ejecutar en todas partes, aún debemos ofrecer una experiencia de primer nivel en cada plataforma. Así que, incluso si estamos usando APIs web, las aplicaciones nativas deben seguir viéndose y sintiéndose nativas porque la UI debe ser verdaderamente nativa. Queremos que los desarrolladores web, que constituyen el 90% del ecosistema de React, puedan construir aplicaciones nativas y usar las APIs que ya conocen. Para que las personas puedan confiar en su conocimiento existente de las APIs más extendidas y bien documentadas de cualquier plataforma, la plataforma web. Este enfoque no requiere un reentrenamiento importante, lo cual es una gran ventaja. Porque acabamos de desbloquear el potencial del conocimiento y habilidades existentes de las personas.

También queremos expandir la audiencia potencial de React Native para incluir a los desarrolladores web estandarizando en APIs web. La nueva arquitectura de React Native hace esto posible. Y eso antes estaba fuera de discusión. Así que evitamos la necesidad de inventar y mantener un conjunto separado de componentes y props específicos nativos. Y esto a su vez debería permitir que React Native se enfoque en sus fortalezas únicas, como las ricas integraciones de código nativo que solo React Native puede ofrecer. Así que React Strict DOM une estos diferentes hilos para que podamos usar el código web existente en nativo hoy. No intenta simular una plataforma en otra. En su lugar, crea una interfaz compartida entre ellas.

Y lo hace explotando dos módulos principales, HTML y CSS, que conectan React Native y React DOM. El módulo HTML es un subconjunto multiplataforma de los componentes que ya conoces de React DOM. Y el módulo CSS es una versión mejorada multiplataforma de la API de hojas de estilo de React Native. En la web, React Strict DOM intencionalmente hace muy poco. Los componentes se ven casi idénticos a los de React DOM. Y no hay sobrecarga en tiempo de ejecución. Las diferencias con React DOM son pequeñas pero deliberadas. Los props están estrictamente tipados. Y el prop de estilo funciona como lo hace en React Native, proporcionando un estilo encapsulado y predecible. En nativo, hay más trabajo sucediendo.

Mapeamos APIs web a APIs nativas. E incluso las instancias de componentes tienen la mayoría de las propiedades y métodos que esperarías de elementos HTML. A pesar de renderizar para uso nativo. El renderizado se mantiene fiel a cada plataforma. La web sigue produciendo HTML. Y las aplicaciones nativas siguen produciendo elementos nativos. El sistema de estilo preserva características clave de React Native, como la encapsulación de estilo y la fusión predecible.

Así que, cuando compones componentes de estilo con React Strict DOM, sabes lo que obtendrás. Eso ha sido estándar en React Native, pero más difícil de lograr en la web. React Strict DOM combina lo mejor de los estilos web y nativos. Las restricciones de nativo que proporcionan esta encapsulación y composición confiable, y las capacidades más amplias de CSS a las que estás acostumbrado en la web.

Así que, lo que obtienes son componentes que se componen de manera predecible, código que puede moverse entre plataformas, y el tipo de portabilidad de ecosistema que React Native ha tenido desde el principio. Esta convergencia con la web es gracias a los avances en React Native que ahora hacen posible los detalles de multiplataforma. La nueva arquitectura de React Native desbloqueó la capacidad de proporcionar APIs sincrónicas y llamar directamente al código nativo, tal como lo hace el navegador. Y React Native ahora soporta el mismo bucle de eventos y APIs de recorrido del DOM que encontrarás en un entorno de navegador, así como un número creciente de características de CSS, como sombras de caja, filtros CSS y gradientes de imagen de fondo. Incluso versiones nativas de APIs web como mutation observer e intersection observer están siendo implementadas.

Y todo esto nos permite reproducir componentes web de React en nativo con más precisión que nunca. React Native no soporta todo lo que necesitamos todavía. Y por eso, React Strict DOM rellena las capacidades web, como propiedades personalizadas de CSS, herencia, unidades relativas, transiciones, y más. Aproximadamente la mitad de las APIs disponibles están rellenas de alguna manera. Y esto nos ayuda a llevar el poder y la familiaridad de la web a plataformas nativas sin esperar a que cada característica sea construida nativamente.

Todo este trabajo para crear una interfaz compartida basada en la web significa que ahora podemos transformar fácilmente gran parte de nuestro código web existente para que funcione en nativo. Usamos transformaciones AST para convertir automáticamente el código de React DOM a React Strict DOM, y modificaciones de código asistidas por IA para conversiones más complicadas. Aunque todavía se requiere algo de refactorización manual para casos extremos, la migración de código se ha vuelto relativamente fácil de automatizar. La dificultad del trabajo para transformar estilos variará dependiendo de la biblioteca de estilos con la que comiences.

Pero una vez que eso está manejado, el resto del camino es bastante fácil. Y esta es una victoria clave para Meta sobre esfuerzos anteriores que requieren migraciones complicadas o la reimplementación de componentes para plataformas nativas. El mismo enfoque también funciona para componentes de React Native. Así que, los equipos que quieren migrar componentes nativos existentes a la web pueden hacerlo relativamente fácil porque el modelo de estilo en React Strict DOM es muy similar al de React Native.

El objetivo de esta canalización de modificación de código es que eventualmente sea de código abierto para que las personas que han invertido en React Native y frameworks como Expo tengan un camino claro y viable para la adopción. Aunque nuestro objetivo es compartir la mayor cantidad de código posible, todavía hay casos donde se necesitan APIs o optimizaciones específicas de la plataforma. Y para estos, simplemente usamos extensiones de archivo específicas de la plataforma para bifurcar el código e ir completamente nativo según sea necesario. Si has usado React Native antes, esta ya es una práctica bien establecida en ese ecosistema. Así que, Meta ha estado construyendo aplicaciones multiplataforma de esta manera durante un par de años.

La aplicación Facebook VR mostrada en MetaConnect en 2024 fue la primera aplicación nativa que construimos a partir de código web existente usando React Strict DOM. Y nos permitió lanzar características más rápido con menos ingenieros y proporcionar una experiencia de Facebook más consistente a través de plataformas. La aplicación reutilizó algunas de las características más complejas y robustas de Facebook.com, como el NewsFeed y el sistema de comentarios. Al compartir código de esta manera, los equipos pudieron pasar menos tiempo en lógica de negocio repetitiva y más tiempo agregando interacciones y experiencias específicas de meta quest. Y lo notable no es solo que reutilizamos código web, sino que la aplicación nativa resultante se ve y se siente casi indistinguible de una construida nativamente. Y esto nos demostró que compartir código con la web no tiene que significar un compromiso en la calidad del producto de una nativa.

Así que, Facebook VR reutiliza alrededor del 60% de los archivos de la web. E incluso en esta etapa temprana, React Strict DOM está renderizando el 10% de los divs y el 20% de los spans en el feed de inicio de Facebook.com ahora. Y durante este proceso, también evitamos casi por completo las regresiones visuales y no vimos regresiones de rendimiento o experiencia de usuario en la web tampoco. Meta está desarrollando actualmente otra aplicación multiplataforma importante que utiliza React Strict DOM. Y esa aplicación hace un uso extensivo de animaciones de resorte. Así que, desarrollamos una solución multiplataforma para animaciones usando React Strict DOM también que estamos en el proceso de hacer de código abierto. En la web, está impulsado por la API de animaciones web y en nativo, el núcleo ha sido reescrito en C++. Esto nos permite diseñar y desarrollar animaciones de alto rendimiento de alta calidad que funcionan en todas las plataformas por primera vez.

Esta nueva aplicación es también la primera aplicación React multiplataforma de Meta construida por ingenieros usando asistencia de codificación AI. Los agentes AI aún no entienden los detalles de React Strict DOM de forma predeterminada porque no fue parte de sus datos de entrenamiento. Sin embargo, debido a que la API de React Strict DOM es intencionalmente muy similar a React DOM, solo necesitamos proporcionar una pequeña cantidad de orientación adicional a los modelos AI en forma de instrucciones y habilidades dedicadas. Y esto permite a los agentes adaptar su conocimiento existente de React DOM y CSS para generar código multiplataforma. Requerir solo una implementación ha sido un gran éxito al usar asistencia de codificación AI. Porque la validación de generación de código multiplataforma reduce la cantidad de tokens necesarios en la entrada y la salida, lo que a su vez reduce los costos de cómputo y el tiempo necesario para completar una tarea.

Así que, unificar el código React de esta manera ha traído muchos beneficios, especialmente para la web, pero también tiene algunas compensaciones en este momento. La compensación más significativa es el costo de tiempo de ejecución en nativo de completar características faltantes en JavaScript. Agregar estas capacidades adicionales en nativo significa que renderizar un div es aproximadamente la mitad de rápido que renderizar una vista. Y aunque encontramos que este costo de rendimiento es generalmente aceptable, incluso en hardware relativamente de baja gama, continuamos buscando formas de mejorar. Y en los últimos 18 meses, mejoramos el rendimiento en aproximadamente dos veces y media. Con el tiempo, a medida que más características se muevan a código nativo y se optimicen, esta brecha se cerrará, porque simplemente no estaremos completando tanto en JavaScript.

Así que, ese es el estado de React Strict DOM hoy. Y voy a hablar un poco sobre lo que creo que podría ser el futuro. Así que, React Strict DOM está ayudando a determinar qué partes de la web queremos llevar a nativo. Este tipo de trabajo siempre ha requerido individuos dedicados que invierten su tiempo y creatividad en problemas como este. Y hoy, personas en Meta, Expo, Software Mansion, Callstack, y en otros lugares son partes interesadas en esta visión. Para que podamos obtener el máximo provecho de esta tecnología, esto es lo que creo que debe suceder a continuación. React Native necesita convertirse en un renderizador web selectivo y de alto rendimiento para un subconjunto de HTML, CSS, y la web. Actualmente soportamos o emulamos alrededor del 60% de la API objetivo en nativo. Pero a medida que unificamos más características, podemos cerrar esa brecha entre plataformas y aumentar aún más el valor de React multiplataforma.

En el pasado, esto parecía bastante improbable, pero las personas que trabajan en React Native han demostrado que ahora no solo es posible, sino beneficioso para nosotros hacer esto. También hay más trabajo por hacer para ofrecer una solución de estilo integrada para React que funcione en todas las plataformas. Tenemos mucho feedback de los equipos internos de Meta, así como de partes interesadas como Vercel y Expo, que queremos incorporar en futuras iteraciones de esta API. La futura solución de estilo de React necesita ser tan simple para las personas y los agentes de AI como el sistema de estilo de React Native ha demostrado ser. Y lograr cosas como esta podría incluso requerir cambios en React mismo. Eso es porque nuestra visión no se trata solo de hacer otra biblioteca de UI. Se trata de consolidar todo nuestro enfoque para construir interfaces de usuario con React. Solo es posible ahora debido al progreso acumulado en React, React Native, Hermes, Flow, Expo, y muchas otras tecnologías. Porque las mejoras en cada parte de este stack han multiplicado el valor de las otras. Así que hoy, podemos construir cosas que habrían sido poco prácticas hace solo unos años.

Desde esa base, necesitamos seguir trabajando hacia una única forma canónica de construir UI con menos fragmentación, menos esfuerzo duplicado entre plataformas, y el tipo de sistema de estilo integrado que React siempre ha merecido. Porque cuando hay una forma clara de describir interfaces interactivas, nuestras herramientas, capacitación e inversiones pueden todas componerse en la misma dirección, y ahí es donde aparece el verdadero valor. También estamos en un momento crítico en el desarrollo de software, donde la cogeneración de AI se está convirtiendo en una parte central de la ingeniería de UI. Para que esto tenga éxito a gran escala, creo que la UI generada debe verse y funcionar igual en todos los contextos. Porque la representación inconsistente o los componentes incompatibles socavan gravemente la promesa de la automatización. El potencial aquí para una biblioteca como React Strict DOM es enorme. Podemos desbloquear flujos de trabajo unificados para nuestros equipos y obtener más ganancias de eficiencia al reducir los costos de cómputo asociados con la generación de código multiplataforma. Ya estamos viendo estos beneficios en Meta. Las plataformas de codificación Vibe también podrían ofrecer más valor a menor costo, permitiendo que estas herramientas amplíen su audiencia generando aplicaciones que funcionen tanto en la web como en plataformas nativas. Al evolucionar nuestras bibliotecas de UI fundamentales de esta manera con APIs universales claras que los LLMs pueden usar fácilmente, podemos construir interfaces de usuario que mejor se ajusten a la intención del diseñador y del desarrollador, sin importar la plataforma.

Lo que quiero que te lleves de esta charla es lo siguiente. El esfuerzo por crear un React para tanto web como nativo está ayudando a Meta a construir nuevas aplicaciones multiplataforma, y creemos que esta es una ventaja clave para el futuro. Estandarizar en la web nos permite capitalizar la enorme adopción existente de React en la web y el trabajo de diseño de API que se ha realizado en la plataforma de aplicaciones más ubicua del mundo. Cuando limitamos cómo construimos, podemos crear compensaciones que funcionen a nuestro favor. Intercambiar algo de flexibilidad para aumentar la predictibilidad es lo que nos permite componer grandes sistemas con más confianza. React Native es una parte clave de esta visión, y necesitamos construir más capacidades si queremos cumplir con este potencial. Y finalmente, la naturaleza de la AI generativa debería inspirarnos a hacer marcos más simples y mejores con los que las personas que usan modelos de AI puedan tener más éxito a largo plazo. Así que, si este es un futuro para React que te inspira, te animo a probar un React strict DOM y ayudar a hacer realidad esta visión para React. Gracias. Muchas gracias por esa gran charla y este, ya sabes, un React para gobernarlos a todos.

Muchas gracias por esa gran charla y este, ya sabes, un React para gobernarlos a todos. Me encanta este sentimiento. Así que, tenemos algunas preguntas diferentes aquí, algunas de las cuales están relacionadas con cosas como nuestros flujos de trabajo existentes. Así que, algunas personas se preguntan, por ejemplo, ¿cómo encajaría algo como Tailwind en este panorama? ¿Es posible usar eso con React strict DOM? Sí, he visto que algunas personas ya han creado transformaciones de Babel sobre la parte superior de React strict DOM que te permiten escribir una sintaxis similar a Tailwind y luego eso se compila al tipo de código que acabo de mostrar. Así que, creo que la forma en que he estado pensando sobre esto es realmente que queremos intentar crear una capa fundamental sobre la cual otras cosas puedan construirse encima.

Y mientras se ajusten, ya sabes, a la semántica de lo que estamos tratando de hacer aquí, entonces podrán construirse encima. Sí. Genial. Genial. Bien. Y así, supongo que en términos de mejores prácticas para construir bibliotecas de UI usando React strict DOM, ¿cómo estructurarías mejor las bibliotecas de componentes del sistema de diseño que tienen componentes comunes tanto para web como para nativo? Bueno, el objetivo es que simplemente escribirías tus componentes web y funcionarían en nativo. Así que, con suerte, todo lo que ya sabes sobre construir bibliotecas de UI para la web se traduciría. Y como mencioné, si necesitas tener implementaciones especiales solo para web o nativo, usar las extensiones de archivo específicas de la plataforma es cómo separarías esos dos. Entendido. Entendido.

Hasta que el resto de las características estén completamente integradas y entonces ni siquiera tendrás que hacer eso. Increíble. Bien. Supongo que tenemos, sí, tenemos otra pregunta aquí que es una especie de comparación y contraste. ¿Cómo ves la relación entre las aplicaciones web progresivas y React strict DOM? ¿Son competidores? ¿Resuelven diferentes problemas? ¿Son complementarios? ¿Cuáles son tus pensamientos al respecto? Sí, creo que son partes diferentes del stack. Así que, si estás desplegando en la web, aún podrías querer producir una aplicación web progresiva, pero la forma en que escribes tus componentes de React es algo separado de eso. Así que, esto es realmente como una biblioteca para simplemente evitar esta separación entre React DOM y React native. Tener solo una forma de escribir código React, una forma que tenemos que enseñar a las personas y a las máquinas, y tratar de tomar lo mejor de ambos. Así que, creemos que la ubicuidad de la plataforma web es su fortaleza, pero algunas de sus desventajas, como la falta de estilo encapsulado, no se alinean realmente con el modelo de componentes de React. Así que, este es un intento de traer encapsulación de estilos, tal como tienes encapsulación de props y todo lo demás. Y así, básicamente, así es como lo veo. Y es bastante diferente de si hacer o no una aplicación web progresiva. Entendido. Bueno, la gente quiere saber, ¿esto se convertirá en parte de React Foundations?

Quiero decir, supongo que veremos si cosas como React Native terminan siendo parte de la fundación. Pero creo que es bueno tener algo como la fundación de React para que proyectos como este y otros proyectos de la comunidad tengan un hogar y una fuente de financiación. Así que, nunca digas nunca. Sí. Me encanta obtener financiación para el código abierto sostenible, en general.

Muy bien. Tenemos las preguntas que siguen llegando. Vaya, realmente has despertado la emoción de la gente. Así que, no olvides que si no tienes la oportunidad de que tu pregunta sea respondida aquí, habrá un espacio de preguntas y respuestas con los ponentes después de la charla fuera de nuestro hermoso planetario hoy. Muy bien.

Siguiendo adelante, ¿qué tal las aplicaciones de Electron? ¿Crees que todavía hay un lugar para otras tecnologías como las aplicaciones de Electron en el contexto de React strict DOM? ¿Todos estaremos construyendo de manera diferente? Bueno, creo que el objetivo es realmente permitir que las personas separen cómo construyo mis componentes en mi aplicación de cómo se implementa o dónde se implementa. Así que, no deberías tener que tomar una decisión de antemano de si voy a hacer una aplicación web, si voy a hacer una aplicación nativa, si voy a usar Electron, si voy a usar vistas web o lo que sea. Queremos que esa decisión esté separada del código que escribes para describir tu aplicación en primer lugar, para que se convierta en una preocupación secundaria después.

en primer lugar, para que se convierta en una preocupación secundaria después. Quiero decir, lo ideal sería, ya sabes, simplemente presionas diferentes botones o ejecutas diferentes banderas y la misma aplicación, puede ser generada en todas estas diferentes formas. Entonces, si quieres ver si una aplicación de electron funciona mejor para mi empresa y lo que estamos tratando de hacer frente a una aplicación nativa, podrías averiguarlo sin tener que reescribir tu código de React.

Así que, realmente se trata de crear como valor de opción para las personas. Genial. Sí.

Y entonces, supongo que todavía hay mucho espacio para la exploración y para reducir las cosas según tu caso de uso individual. Sí, exactamente. Entendido.

Muy bien. Y así, supongo que hay, sí, hay un par de preguntas sobre la preparación que podemos, ¿podemos empezar a construir con esto ahora mismo? ¿Puedo ir a mi portátil mientras hablamos y empezar a poner React strict DOM ya en nuevas aplicaciones de producción, incluso a una escala media? Sí, quiero decir, podrías intentarlo. Y volver a ti con cualquier comentario. Sí. Increíble.

Y ahora estamos, sí, ahora estamos entrando en las preguntas interesantes. ¿Podemos deshacernos de la sintaxis HTML en un nuevo compilador? Sí. Quiero decir, creo que la razón por la que tenemos eso es, ya sabes, es muy confuso si entras en un archivo y parece código que estás escribiendo antes, pero se comporta de manera diferente. Especialmente con la forma en que hemos fusionado el estilo y los elementos juntos, más como React Native. Así que, quiero decir, no voy a descartar que en el futuro, si algo como esto realmente despega y simplemente tiene sentido que, ya sabes, digamos que todos están escribiendo código de esta manera, entonces tal vez esto sería lo que React DOM parecería por defecto.

Pero creo que en esta etapa tiene sentido para nosotros mantenerlos separados porque todos los sistemas que tenemos, ya sea code mods o agentes de IA, estos son pequeños signos que pueden usar para entender cuándo están cambiando a otro modo o no. Y como la pregunta anterior sobre, ¿puedo usar esto en una aplicación de tamaño medio o lo que sea, es como, si quisieras deshacer esa elección. Así que hablé sobre lo fácil que es para nosotros migrar nuestro código web existente a esta sintaxis.