Nitro Engine: Redefining Performance in the Expo New Architecture

For years, we’ve lived with the "Bridge Tax." If you’ve been in the React Native ecosystem as long as I have, you know the drill: you write a high-performance native module, only to watch your frames drop because of the overhead of JSON serialization and asynchronous batching.

With the shift to the New Architecture and JSI (JavaScript Interface), the game changed. But recently, I’ve been digging into the Nitro Engine, and it feels like the breakthrough we’ve actually been waiting for. It’s not just an improvement; it’s a fundamental rethinking of how JS and Native code should communicate.

Why Nitro? The Bottleneck Problem

Even with TurboModules, there’s often a layer of boilerplate and codegen that can feel restrictive. When I’m building something that requires heavy computation—think real-time image processing or high-frequency sensor data—I don't want a "wrapper." I want direct access.

Nitro, pioneered by Marc Rousavy and adopted within the high-performance Expo ecosystem, is a C++ centric engine designed to make native modules nearly as fast as calling a local function. It skips the traditional bridge entirely and uses JSI to expose C++ HostObjects directly to the JavaScript runtime.

The Engineering Breakthrough: Zero-Copy

The most impressive part of Nitro’s design is the focus on Zero-Copy. In the old bridge world, if you passed a large array from JS to Native, the engine had to stringify it, pass it over, and parse it back into a native type.

With Nitro and JSI, we are sharing memory. When I define a Nitro module, I’m essentially creating a C++ object that the JS engine treats as a first-class citizen.

What the Code Looks Like

Unlike the standard TurboModule setup which can feel like writing Java/Obj-C with a lot of glue code, Nitro leverages modern C++ to define the interface. Here’s a conceptual look at how I’ve been implementing high-speed math functions:

#include <NitroModules/HybridObject.hpp>

class MyFastModule: public margelo::nitro::HybridObject {
public:
  MyFastModule() : HybridObject("MyFastModule") {}

  // This function is called directly from JS with almost zero overhead
  double calculateComplexPhysics(double input) {
    return input * 42.0; // Imagine heavy physics logic here
  }

  void loadHybridMethods() override {
    // Registering the method to the JS runtime
    registerHybrids(this, [](Prototype& prototype) {
      prototype.registerMethod("calculateComplexPhysics", &MyFastModule::calculateComplexPhysics);
    });
  }
};

On the JavaScript side, it feels like magic. No NativeModules.MyFastModule.calculateComplexPhysics(). Instead, you interact with a typed, synchronous object.

Why This Matters for Expo Developers

Expo has been pushing the boundaries of the "Managed Workflow" for a long time. But for those of us doing "heavy lifting," the managed workflow sometimes felt like a golden cage. Nitro changes that by providing a standardized, ultra-fast way to inject C++ logic into Expo apps without breaking the developer experience.

1. Type Safety: Nitro’s codegen ensures that your TypeScript types and your C++ types stay in sync. No more runtime crashes because you passed a string where an int was expected.
2. Synchronous Execution: Sometimes async/await is a hurdle, not a feature. Nitro allows for synchronous calls to native logic, which is critical for UI-blocking calculations or frame-rate-dependent logic.
3. Modern C++: It encourages using modern C++17/20 standards, making the native side much cleaner and more maintainable than the legacy JNI (Java Native Interface) patterns.

My Experience: The "Feel" of Performance

I recently refactored a signal processing module from a standard TurboModule to a Nitro-based Hybrid Object. The difference wasn't just in the benchmarks; it was in the responsiveness of the UI. When the JS thread doesn't have to wait for the bridge to clear its queue, everything feels "snappy."

We are moving toward an era where the distinction between "Native" and "JavaScript" is blurring. With Nitro, the native code is simply an extension of the JS runtime's capabilities.

Conclusion

If you are building an app that moves a lot of data or requires real-time processing, the Nitro Engine is your best friend. It represents the maturity of the New Architecture, moving beyond just "fixing the bridge" and toward a high-performance C++ core for the entire React Native ecosystem.

It’s time to stop thinking about native modules as "plugins" and start thinking about them as high-performance extensions of your logic. Nitro is the engine that makes that possible.