¿Cómo funciona en realidad la arquitectura de React Native: el bridge frente al nuevo JSI/Fabric/TurboModules?

El discurso de React Native siempre fue "escribís JavaScript y obtenés vistas nativas de verdad", y la mayoría de los candidatos puede describir hasta ahí. Lo que distingue a una respuesta senior es conocer la cañería que hace eso posible: cómo una llamada hecha desde el hilo de JS termina convirtiéndose en un UIView o un android.view.View, y por qué Facebook pasó años reescribiendo esa cañería desde cero. Acá hay en realidad dos arquitecturas para conocer: la clásica, que todavía corre en la mayoría de las apps en producción, y la New Architecture (JSI, TurboModules, Fabric), que hoy es el default para proyectos nuevos.

#La arquitectura clásica: tres hilos y un bridge

React Native clásico corre (al menos) tres hilos. El hilo de JS ejecuta tu código de aplicación y el reconciliador de React sobre un motor de JS (históricamente JavaScriptCore, hoy generalmente Hermes). El hilo Shadow corre Yoga, el motor de flexbox en C++ que convierte tus estilos en un árbol de layout. El hilo principal/UI es dueño de las vistas nativas reales — UIView en iOS, View en Android — y es el único hilo autorizado a tocarlas.

Ninguno de esos hilos comparte memoria directamente. Cada vez que el hilo de JS necesita algo de nativo — llamar a un módulo nativo, pedir una medición de layout, mutar el árbol de vistas — el mensaje tiene que serializarse a JSON, encolarse, y agruparse en lotes: React Native no manda mensajes uno por uno, vacía la cola una vez por tick del event loop de JS para amortizar el costo de cruzar el bridge. Del otro lado, nativo deserializa el JSON, hace el trabajo, y si se espera una respuesta, serializa una respuesta y la manda de vuelta por el mismo camino.

Esa línea de "ninguna llamada síncrona" es la que de verdad duele en producción. Cualquier cosa que necesite una respuesta nativa ya mismo — medir una vista antes de decidir cómo animarla, leer un scroll offset en medio de un gesto, manejar una transición de elemento compartido — tiene que esperar al menos un viaje redondo por el bridge, y bajo carga (una lista larga renderizando, varios módulos nativos disparando a la vez) esa cola se satura. Este es el mecanismo concreto detrás del jank que le dio a React Native su mala fama inicial, no algo vago como "JavaScript es lento".

#La New Architecture: JSI reemplaza al bridge, no lo apura

La solución no fue un bridge más rápido — fue eliminar el concepto de bridge. JSI (JavaScript Interface) es una capa en C++ embebida directamente en el runtime de JS que permite que un objeto de JS tenga una referencia real a un objeto de C++ (un HostObject) y llame a sus métodos directamente, de forma síncrona, sin serialización. Una llamada por JSI es una llamada de función en C++, no un mensaje JSON en una cola — argumentos y valores de retorno cruzan el límite como valores reales, no como texto.

Los TurboModules son módulos nativos reconstruidos sobre JSI. Cambian dos cosas respecto a los viejos NativeModules: se instancian de forma perezosa (un módulo recién se crea la primera vez que JS lo toca, por eso las apps con New Architecture tienen un cold start visiblemente más rápido cuando hay muchos módulos), y su interfaz del lado de JS se genera con Codegen a partir de una especificación tipada (Flow o TypeScript), así el lado nativo y el lado JS de un módulo se validan contra el mismo contrato en vez de confiar en una firma de bridge escrita a mano.

Fabric es el renderer construido de la misma forma. En la arquitectura clásica, el "Shadow Tree" y el UIManager también cruzaban el bridge para confirmar mutaciones de vistas en el hilo principal. Fabric mantiene el shadow tree en C++, compartido directamente con JS a través de JSI, así un layout puede medirse o confirmarse de forma síncrona cuando la situación lo requiere, y las mutaciones de vistas ya no esperan una cola serializada y agrupada en lotes. Fabric también es lo que permite que React Native se enchufe correctamente al modelo concurrente de Fiber de React — las prioridades y la interrupción pueden respetarse cruzando el límite JS/nativo en lugar de detenerse ahí.

Juntando todo, desde RN 0.74+ se puede correr en modo bridgeless: el objeto del bridge legado ni siquiera se instancia, y JSI es el único camino entre JS y nativo. Todo lo anterior — JSI, TurboModules, Fabric, Codegen, el modo bridgeless — es lo que la gente llama "la New Architecture"; se lanzó como default para apps nuevas, y la mayoría de las librerías existentes se alcanzaron mediante una capa de interoperabilidad mientras sus mantenedores las portaban de forma nativa.

#Qué gana realmente con esto, en concreto

Una buena respuesta nombra consecuencias reales, no sólo los nombres de los componentes: medición de layout síncrona sin un viaje redondo extra, un costo de serialización/deserialización JSON considerablemente menor en apps que mueven mucha información a través del límite (apps de chat, apps con listas grandes, cualquier cosa que llame módulos nativos en un loop caliente), cold start más rápido gracias a TurboModules perezosos en vez de construir cada módulo nativo de entrada, y menos rotación de memoria porque valores grandes (como buffers de imágenes) pueden referenciarse en vez de copiarse a través de un string JSON. La salvedad honesta que vale la pena agregar: la adopción fue gradual, algunas librerías nativas de terceros tardaron en publicar componentes Fabric de verdad, y la capa de interoperabilidad — aunque hizo que la mayoría de las librerías existentes "simplemente funcionaran" — es un detalle real de migración, no una nota al pie, para un equipo que mantiene un código base grande de RN hoy.

🧠 Bridge vs. New Architecture
0/3 · 0/3 answered
1. ¿Cuál era la limitación fundamental del bridge clásico de React Native?
Toda llamada era asíncrona y se serializaba a JSON, por lo que no era posible ninguna llamada nativa síncronaSólo funcionaba en AndroidNo podía mandar más de un mensaje por segundoRequería una conexión WebSocket a un servidor de desarrollo en producción
2. ¿Qué afirmación distingue correctamente JSI, TurboModules y Fabric?
JSI es una librería de componentes de UI, TurboModules es una herramienta de testing, Fabric es un sistema de buildSon tres nombres intercambiables para la misma optimizaciónJSI es el mecanismo de llamada directa en C++; los TurboModules son módulos nativos construidos sobre él; Fabric es el renderer construido sobre élFabric reemplazó JavaScript por Kotlin
3. ¿Por qué los TurboModules mejoran el tiempo de cold start frente a los módulos nativos clásicos?
Corren en un proceso separado en segundo planoSe saltan por completo el layout de YogaSe instancian de forma perezosa en el primer uso en vez de crearse todos de entrada al arrancarEstán escritos en un lenguaje más rápido