Performance trade-offs of abstracting native UI

WHAT THIS TESTS The interviewer probes deep understanding of the React Native execution model and realistic mitigation, not buzzwords. The classic pain point is list scrolling, which exposes the boundary cost.

A GOOD ANSWER COVERS Explain that the abstraction layer separates JavaScript logic from native views. In the classic architecture, communication crosses an asynchronous bridge that serializes messages between the JS thread and the native UI thread; high-frequency updates like fast scrolling a long list can saturate the bridge or the JS thread and drop frames. Mitigations: use a properly virtualized list (FlatList, or FlashList for better recycling) so only visible rows mount, minimize per-item bridge chatter and re-renders, memoize rows and keep item layout cheap, and push hot or animation-critical paths into native modules or use the newer Fabric renderer and JSI which remove the serialized bridge. Profile with both the JS profiler and the native frame/UI-thread tools (and the perf monitor) to locate whether the bottleneck is JS, the bridge, or rendering.

COMMON WRONG ANSWERS Blaming JavaScript being slow, when the real cost is the bridge and thread coordination. Skipping virtualization and rendering the whole list. Profiling only JavaScript and missing native-thread or bridge saturation.

LIKELY FOLLOW-UPS How does Fabric/JSI change the bridge story? When do you drop to a native module? How do you measure dropped frames specifically?

ONE CONCRETE EXAMPLE A chat screen with thousands of messages jank-scrolls. Profiling shows the JS thread is fine but the bridge floods with layout messages. You switch from a naive map to FlashList for recycling, memoize each row, remove inline functions causing re-renders, and confirm with the frame profiler that dropped frames vanish; for a custom gesture-heavy header you write a small native module to keep it off the bridge.