JSI, Fabric, and TurboModules in the New Architecture

WHAT THIS TESTS Whether you understand how JSI, Fabric, and TurboModules replace the old asynchronous bridge and what each contributes.

A GOOD ANSWER COVERS The legacy architecture passed all JS-to-native communication through a single bridge that serialized calls to JSON, queued them, and delivered them asynchronously, creating a throughput bottleneck and forcing everything to be async. The New Architecture rests on JSI, a slim C++ layer that lets the JavaScript engine hold direct references to native objects and invoke them synchronously without serialization, and it decouples React Native from a specific JS engine. Built on JSI, TurboModules expose native modules lazily, initializing each only when first accessed rather than loading every module at startup, improving launch time and memory. Fabric is the new rendering system, with a C++ core and a shared shadow tree that both threads can read, enabling concurrent rendering features and synchronous measurement and layout where needed. Collectively they remove the serialization tax, allow synchronous interop, and reduce startup overhead.

COMMON WRONG ANSWERS Saying the bridge is merely faster but still routes JSON messages; JSI replaces that path. Conflating Fabric and TurboModules, or thinking TurboModules render UI. Claiming JSI makes everything synchronous; it enables synchronous calls but async patterns remain common.

LIKELY FOLLOW-UPS How codegen generates the typed bindings these rely on. How Fabric's shadow tree differs from the old UIManager. The migration implications for existing native modules.

ONE CONCRETE EXAMPLE Reading a value from a native module under the old bridge meant an async round trip through a serialized queue. With a TurboModule over JSI, JavaScript holds a host object and calls the method directly in C++, returning the value synchronously, while Fabric commits UI updates through its shared shadow tree.