Módulos Nitro: Cómo las vinculaciones estáticas superan a React Native TurboModules
Explica cómo los módulos Nitro utilizan enlaces estáticos precompilados en lugar de búsquedas dinámicas para superar con creces a los módulos TurboModules y Expo Modules en React Native.
TurboModules se suponía que serían la solución. Reemplazaron a la obsoleta arquitectura de puente, eliminaron la sobrecarga innecesaria y se convirtieron en el enfoque aceptado para escribir código nativo que interactúa con JavaScript. Luego apareció una biblioteca más reciente llamada Nitro Modules que hizo que esa “solución definitiva” pareciera obsoleta.
Los resultados de pruebas publicados demuestran que, al probar una llamada a función síncrona idéntica, los módulos Nitro pueden superar en rendimiento a los módulos Expo hasta en un factor de 59, y superar a los TurboModules aproximadamente 15 veces. Incluso cuando están involucradas cadenas de texto, que suelen añadir carga adicional al pasar entre JavaScript y código nativo, Nitro sigue manteniendo una ventaja de 5 a 13 veces. Al transferir cargas más grandes como imágenes o buffers sin procesar, Nitro logra otra mejora del 8 al 40 por ciento, gracias a un enfoque de copia nula que evita duplicar datos en la memoria.
Números de esa magnitud exigen una explicación. ¿Qué está haciendo exactamente Nitro en el fondo, y por qué este diseño no apareció antes?
El problema que nadie más había resuelto
Nitro no fue diseñado como un ejercicio de referencia. Surgió del trabajo de Marc Rousavy, creador de VisionCamera, como respuesta a una limitación muy concreta: ni TurboModules ni Expo Modules podían soportar adecuadamente el procesamiento de fotogramas.
Imagínese un único fotograma de cámara en VisionCamera como algo similar a un búfer de 10 megabytes. Ese búfer no puede ser copiado a través del puente de comunicación, ni siquiera con TurboModules, y tampoco cabe en una estructura similar al JSON. Lo que realmente necesitaba Rousavy era una forma de pasar directamente a JavaScript un objeto nativo complejo y con estado, escrito en C++ o Swift, completo con métodos y propiedades funcionales. TurboModules no contaba con mecanismo alguno para ese tipo de objeto.
Por lo tanto, Nitro fue creado específicamente para hacer eso posible, y las notables mejoras en velocidad resultaron ser un beneficio adicional que acabó atrayendo mucha más atención que el problema original que resolvía.
Una sola decisión arquitectónica
La verdadera diferencia entre TurboModules y Nitro se reduce a una decisión de diseño: cómo cada sistema representa un objeto nativo una vez que está dentro del motor de JavaScript.
TurboModules dependen de jsi::HostObject. Cada vez que el código JavaScript accede a una propiedad o invoca un método en uno de estos objetos, el entorno de ejecución debe resolver ese acceso dinámicamente, en tiempo real. Esta búsqueda tiene lugar en cada llamada, y ese costo repetido se acumula rápidamente en los módulos que se invocan con frecuencia.
Nitro sigue un enfoque diferente, utilizando jsi::NativeState. En combinación con una herramienta de generación de código llamada Nitrogen, genera por adelantado todos los enlaces necesarios en C++, Swift o Kotlin, antes incluso de ejecutar la aplicación. Nada se resuelve dinámicamente en tiempo de ejecución. La conversión entre JavaScript y tipos nativos se compila estáticamente con antelación, lo que significa que invocar un módulo de Nitro se comporta más como llamar a una función ordinaria que como cruzar un puente en tiempo de ejecución.
Ese cambio, enlaces estáticos precompilados en lugar de búsquedas dinámicas en tiempo de ejecución, explica la mayor parte de la diferencia de rendimiento observada en las pruebas de rendimiento.
Dentro de Nitro, cualquier objeto nativo, ya sea escrito en C++, Swift o Kotlin, se denomina Objeto Híbrido. Nitrogen analiza una definición de interfaz en TypeScript y genera automáticamente el código necesario para transferir ese objeto más allá de los límites del entorno nativo de JavaScript, incluyendo el manejo de enums, uniones y estructuras. Esta herramienta es precisamente lo que permitió a Rousavy exponer algo tan poco convencional como un fotograma de cámara en vivo, sin tener que escribir manualmente código de puente separado para cada una de las tres plataformas.
Por qué esto va más allá de una simple biblioteca
VisionCamera sirvió como prueba inicial de que este enfoque funcionaba, pero el diseño de Nitro nunca estuvo pensado para ser una solución única para un único caso de uso. Su arquitectura brinda a cualquier módulo nativo soporte integrado para buffers de array, objetos nativos con estado y interoperabilidad directa con C++, capacidades que, bajo los enfoques anteriores, eran a mejor tardar poco prácticas o completamente inviables.
El ecosistema más amplio de React Native ha comenzado a darse cuenta de esto. Proyectos como react-native-nitro-cache, junto con herramientas orientadas al caché de imágenes, cargas de trabajo de aprendizaje automático y motores de juegos, se están reconstruyendo sobre Nitro específicamente para reducir la sobrecarga al convertir JavaScript en código nativo en aquellos aspectos donde el rendimiento es crucial. Esto refleja una tendencia más amplia ya en marcha en React Native, donde las bibliotecas fundamentales se están reestructurando en torno a la Nueva Arquitectura en lugar de tratarla como algo opcional para adoptar posteriormente. La adopción de Nitro está aún muy por detrás de TurboModules, que sigue siendo la opción predeterminada para la mayoría de las bibliotecas, pero la trayectoria es inequívoca. Dondequiera que el rendimiento bruto sea la prioridad, Nitro es cada vez más la primera herramienta a la que recurren los desarrolladores.
Qué significa esto para los autores de módulos nativos
Si actualmente mantienes un módulo nativo, este cambio merece tu atención. Los TurboModules no desaparecerán pronto, y en el caso de módulos sencillos, es probable que la diferencia de rendimiento no sea perceptible para los usuarios finales. Pero si tu módulo implica algo sensible al rendimiento, una alta frecuencia de llamadas, grandes volúmenes de datos o objetos que no se pueden mapear correctamente a JSON, Nitro es ahora muy probablemente la base más sólida sobre la cual construir.
Elegir comenzar un módulo nativo completamente nuevo en TurboModules en 2026 significa, en efecto, trabajar sobre una arquitectura que ya ha sido superada por una alternativa más rápida y en constante desarrollo. El generador de código de Nitro se encarga automáticamente de gran parte del trabajo repetitivo en las tres plataformas al mismo tiempo, y el resultado es un funcionamiento más rápido con menos código nativo escrito a mano para su mantenimiento. Para los equipos que ya cuentan con un TurboModule, la migración no es algo sencillo como simplemente cambiar un interruptor, pero los mismos resultados de rendimiento que hacen atractivo a Nitro también constituyen una sólida razón para programar esa migración lo antes posible.
React Native ya ha vivido varios verdaderos puntos de inflexión arquitectónicos: el abandono del enfoque anterior, la introducción de la Nueva Arquitectura y ahora este. Nitro no surgió respaldado por una orden oficial de Meta; apareció porque un desarrollador necesitaba una funcionalidad que TurboModules simplemente no podía ofrecer, desarrolló la solución de forma pública y dejó que los resultados de las pruebas hablasen por sí mismos.
Lecturas relacionadas
- React Native, Flutter y más allá: las aplicaciones móviles multiplataforma en 2026 — Un análisis comparativo de React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript y PWA en términos de rendimiento, experiencia del desarrollador y madurez del ecosistema.