TurboModules and lazy loading benefits
new-architecture native modules.
TurboModules use JSI for direct, synchronous, type-safe calls and are loaded lazily on first use instead of all at startup, cutting init time.
WHAT THIS TESTS The interviewer wants to confirm you understand the new architecture's native modules, how JSI removes bridge overhead, and why lazy initialization helps startup.
A GOOD ANSWER COVERS A TurboModule is a native module under React Native's new architecture, built on the JavaScript Interface (JSI) rather than the legacy asynchronous bridge. With JSI, JavaScript holds a direct reference to the native object and invokes methods through C++ host objects, so calls can be synchronous and avoid JSON serialization and the batched async queue that the old bridge required. Codegen generates strongly typed interfaces from a JS/TS spec, giving type safety across the boundary and reducing runtime errors. The second improvement is lazy loading: with traditional modules, all registered native modules are typically instantiated at app startup, adding to launch time even for modules the user may never trigger. TurboModules are instead initialized on demand, the first time JavaScript actually accesses them, so the app does less work at launch. This shortens initialization and improves time-to-interactive, especially in large apps with many native modules, since only what is used gets created.
COMMON WRONG ANSWERS Saying TurboModules still serialize over the asynchronous bridge misses the entire point of JSI. Claiming all TurboModules load eagerly contradicts the lazy-initialization benefit. Conflating TurboModules (logic) with Fabric (the renderer) is inaccurate, though both are parts of the new architecture. Believing JSI makes every call synchronous regardless of the work ignores that you still choose async for heavy tasks.
LIKELY FOLLOW-UPS What is codegen's role? It generates type-safe native and JS interfaces from a spec. How does JSI relate to Fabric? Fabric is the new renderer also built on JSI; TurboModules are the module system. Are sync calls always good? No, heavy work should still be async to avoid blocking JS.
ONE CONCRETE EXAMPLE An app with thirty native modules, of which a user session touches three, only instantiates those three TurboModules on first access instead of all thirty at launch, so startup is faster. When JS calls turboModule.getValue(), JSI invokes the native method directly and can return synchronously without a serialized round trip.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.