The "React Native Reference" series briefly touched on the old bridge and the rough idea of JSI (the "Bridging" topic). This chapter goes considerably deeper: WHY was the entire architecture rebuilt, WHAT exactly changes technically, and what does that mean IN PRACTICE for our project?

The old problem: the JSON bridge

In the classic architecture (up to React Native 0.70), the JavaScript and native sides communicated EXCLUSIVELY over a bridge: every call ("render this view", "read the camera permission") got packed into a JSON-serializable message format, sent ASYNCHRONOUSLY across the bridge, and DESERIALIZED again on the other side. Three structural problems: (1) JSON serialization costs time AND memory on every single call, (2) all bridge communication is FORCED to be asynchronous, even when a value would actually be available immediately (e.g. querying a simple device property), (3) all available native modules get loaded IN FULL at app start, even if a session never uses them.

JSI: the fundamental shift

JSI (JavaScript Interface) replaces the bridge with a C++ layer that gives JavaScript objects DIRECT, SYNCHRONOUS access to native C++ objects – no JSON, no serialization, no forced asynchrony. JavaScript can call a native function JUST LIKE a normal JS function, with an immediate return value, when the task allows it.

Fabric: the new rendering engine

Fabric is the JSI-based reimplementation of the rendering system – remember the shadow thread from the "React Native Reference" series (the Yoga engine computes flexbox layout in the background)? Fabric allows layout measurements to be queried SYNCHRONOUSLY where needed (e.g. "how tall is this view actually rendered right now?"), instead of being forced to wait through an asynchronous bridge round trip. The "shadow tree" now lives directly in C++, no longer as a separate copy synchronized over the bridge.

TurboModules: loading native modules on demand

TurboModules replaces the old "native modules" system – the most important practical difference: modules only get loaded on FIRST actual access ("lazily"), no longer unconditionally at app start. If your app, say, only uses expo-camera on a single, rarely visited screen, the native camera code only gets loaded once that screen is actually reached – a faster app start for every user who never opens that screen.

In practice: checking the New Architecture status

Since React Native 0.76, the New Architecture is the DEFAULT for new projects (analogous to Hermes from the last chapter). The status can be inspected/controlled in app.json:

{
  "expo": {
    "newArchEnabled": true
  }
}

Surprise: you're already using JSI without knowing it

zustand and @reduxjs/toolkit from chapters 2-3 are pure JavaScript libraries, they don't touch JSI directly. BUT: @react-native-async-storage/async-storage from "React Native for Beginners" is already a native module – its modern version communicates via TurboModules/JSI, without our own code needing to change at all. That's EXACTLY the point of the new architecture: existing JavaScript code (AsyncStorage.getItem(...)) works UNCHANGED, the performance improvement happens TRANSPARENTLY underneath.

When you actually need to know this

• When integrating some older, long-unmaintained native module libraries – some don't fully support the New Architecture yet (a "backward compatibility mode" is needed, with reduced benefits).
• When writing YOUR OWN native modules (Swift/Kotlin code that communicates with JavaScript) – the API for that has fundamentally changed with TurboModules/Fabric (see the next chapter for the concept, without writing native code yourself).
• With performance-critical libraries like react-native-reanimated (next chapter), which use JSI DIRECTLY and DELIBERATELY to communicate synchronously with the UI thread.