What's the difference between bridging a module with C++ or with JSI in React Native?

Question

In React Native it is possible to bring native functionality from Android and iOS in multiple ways. I always thought that all possible ways were limited by platform-related languages like Java/Kotlin and Objective-C/Swift. However, I noticed that it is still possible to bridge native functionality even from C++ (without using JSI). Specifically, I noticed that from react-native-builder-bob it is possible to easily start a package that bridges native modules using C++.

At this point I wonder, but what does JSI introduce that is new if it was already possible to integrate JS with C++? Why should it bring performance improvements over the current solution?

I apologise in advance for my lack of knowledge, but I really couldn't find the answer.

Answer 1

The current React Native Bridge architecture between Native and JS works asynchronously and transfers data in JSON only.

It produces the following issues:

Async calls

• Many threads and jumps across them: JS, Shadow, Main, Native...
• JS and Main threads do not directly communicate (slow UI rendering)

JSON

• No data sharing between JS and Native threads
• Slow data transfer because of JSON serialisation (bottleneck)

You can make the bridge to any native code Java/Konlin, ObjC/Swift, C++ etc. but you always have the problems from above.

React Native JSI provides an API to the JS Runtime engine and exposes native functions and objects to JS directly - no bridge at all.

It provides the following advantages:

• Sync call from JS thread to Native and vice-versa
• Fast rendering using direct call to UI Main thread
• Data sharing between threads

You have to use C++ only to work with JSI because the JS Runtime has a C++ API but it is possible to make C++ layer between JSI and your existing Java or Swift code.

JSI is the foundation for future new React Native architecture which includes: Fabric, TurboModules, CodeGen. Read more: https://github.com/react-native-community/discussions-and-proposals/issues/91