Contrast the legacy bridge with JSI

WHAT THIS TESTS: Whether you can articulate the structural differences between the two communication models and reason about their performance consequences.

A GOOD ANSWER COVERS: The legacy bridge sits between two threads that cannot share memory. Every interaction is serialized to JSON, queued, batched, and delivered asynchronously, so JS can never synchronously read a native value and high message volume causes backpressure and dropped frames. JSI replaces this with a thin C++ layer that exposes native objects as host objects directly to the JavaScript engine. JS can call native methods without serializing arguments and, where appropriate, synchronously, because there is a direct reference rather than a message queue. The performance implications are lower per-call latency, elimination of the JSON serialization cost, the ability to do synchronous layout reads in Fabric, and lazy initialization of TurboModules that improves startup.

COMMON WRONG ANSWERS: Saying JSI is simply a faster or compressed bridge. Claiming data is still serialized. Asserting everything is now synchronous and free; long synchronous native calls still block the single JS thread. Confusing JSI itself with Fabric or TurboModules, which are built on top of it.

LIKELY FOLLOW-UPS: How host objects expose methods to JS, what CodeGen does, the danger of blocking the JS thread with sync calls, and how memory ownership crosses the JS-C++ boundary.

ONE CONCRETE EXAMPLE: Reading a synchronous configuration value under the bridge required an async callback round trip through JSON. The same value via a JSI-backed TurboModule is returned directly and synchronously as a primitive, with no queue and no serialization, so call sites are simpler and measurably faster.