The React Native Bridge: Why It's Being Replaced

WHY IT EXISTS The React Native Bridge was created to allow the JavaScript thread, where your app logic lives, to communicate with the main native UI thread. This separation is key to React Native's design, as it prevents heavy JS computations from freezing the user interface. The Bridge acts as the necessary communication layer between these two worlds.

THE MENTAL MODEL Think of the Bridge as a translator passing serialized JSON messages between two separate threads: the JavaScript thread and the Native thread. This process is asynchronous by nature. Any action, like a button tap or a render update, is bundled into a message, sent across the Bridge, and processed on the other side. This inherent delay is the source of its main limitations.

HOW IT WORKS When your React component needs to render or update, React Native creates a JSON description of the UI changes. This JSON message is sent asynchronously across the Bridge to the native side. The native platform then interprets this message and executes the actual UI operations, like creating or updating a native view. The same happens in reverse for native events like touches, which are serialized and sent from the native side to the JS thread.

WHEN TO USE IT You don't choose to use the Bridge directly; it's the default, underlying mechanism in legacy React Native versions (before the New Architecture became available around v0.68). Any standard component interaction or native module call in an older app relies on it implicitly.

WHEN NOT TO USE IT The entire React Native ecosystem is moving away from the Bridge because its asynchronous, serialized nature is a performance bottleneck. It prevents synchronous access to UI layout information, which is a major footgun. For example, trying to measure a component's size with onLayout and then immediately update another component's position often results in a visual "jump," as the update happens in a later render cycle. It also blocks the use of modern React 18 features like Suspense and automatic batching.

ONE CANONICAL EXAMPLE Positioning a tooltip above a button. In a Bridge-based app, you must first render the button, then use the onLayout callback to get its screen coordinates. This callback is asynchronous. By the time your JS code receives the coordinates and updates the tooltip's position, the screen may have already painted the tooltip in a default location. The result is a flicker or "jump" as the tooltip moves to its correct spot. The New Architecture's synchronous capabilities solve this, allowing measurement and rendering in a single, seamless step.