Choosing between Hermes, JSI, NAPI, or TurboModules for library authors

[shamilovtim]

Hello given the recent efforts to integrate NAPI into Hermes I am seeking clarity on which APIs should be built on. We will have many ways of building performant adapters:

1. Hermes extensions (e.g. atob, btoa, TextEncoder, etc.)
2. JSI (several community authored web specs like react-native-quick-base64, react-native-buffer, etc.)
3. Node API (TBD)
4. TurboModules (iOS, Android, partial Blob and a couple of other web APIs)

I have observed that some first party web specs have been implemented using the TurboModules API. For example there is a partial, spec incompliant Blob that's part of the React Native runtime which is written as a TurboModule. It appears more logical to use native C++ for these implementations, as it would allow direct code reuse from browser implementations.

Recent development for atob, btoa, and TextEncoder were effectively implemented as extensions on Hermes, which contrasts with the approach taken for Blob.

How will library authors decide which of these 4 APIs to build on? TurboModules seems clear cut for native SDKs bridging iOS or Android to React Native. The addition of C++ TurboModules makes this choice a little more confusing. However for implementing Javascript APIs its unclear how library authors will make a determination for which of these APIs to build on.

[tmikov]

This is a very good question.

Let me break down the alternatives:

Hermes Builtins

Hermes builtins (atob, etc) use the private Hermes APIs, so they are fairly difficult to write and maintain. However, they are by far the most efficient ones, the other approaches do not even come close in overhead. Whether that matters or not depends on what the API is, of course.

Additionally, Hermes builtins are the most convenient for JS developers, since they provide first party supported functionality out of the box. This combination of convenience and performance is unbeatable.

We (the Hermes team) plan to continue adding more such functionality, eventually resulting in a rich SDK, linked on-demand (so binary size increases only for things that are used).

Contributions from the community are accepted, but admittedly the bar is pretty high and the process for landing a PR can be long.

Hermes Builtins in Typed JS

Static Hermes opens a huge new area of possibility, where "builtins" with C++ performance and access to native APIs can be written in typed JavaScript, while still used by "regular untyped JS". We intend this to become an easy way for adding functionality to the "Hermes SDK".

This is still WIP, but it is worth knowing what direction we are moving.

Node API

We are adding Node API primarily to enable existing native extensions to work with Hermes. Further, some projects like Native Script strongly prefer Node API.

We don't really envision it becoming a major way for adding new extensions to React Native, but at the same time we are certainly not doing anything to prevent it.

JSI and Turbo Modules

I am putting these under the same section, because Turbo Modules are implemented on top of JSI. JSI is engine-level while Turbo Modules is an additional abstraction provided by React Native, but in practice they are both used by React Native apps. From the point of view of Hermes, they are equivalent. From here on, when I say "JSI" I mean JSI/TurboModules.

JSI is by far the most practical way to easily develop native extensions, far easier than Node API. Additionally, it is the only way to develop extensions that are compatible between all React Native engines: JSC, v8, Hermes...

So, we expect that for the foreseeable future this will be the main way for adding native extensions.

Now, to be completely honest, the Hermes team does not have a lot of expertise in React Native. We have never used Turbo Modules and we don't understand them well. So, if it was my personal choice, I would use JSI, since it gives me control and a good balance between performance and ease.

But I am happy to learn more about Turbo Modules and hear opinions on this discussion.

[shamilovtim]

Hermes Builtins
Hermes builtins (atob, etc) use the private Hermes APIs, so they are fairly difficult to write and maintain. However, they are by far the most efficient ones, the other approaches do not even come close in overhead. Whether that matters or not depends on what the API is, of course.

I take it the Hermes builtins don't use similar code to the browser runtimes because they're implemented on the engine rather than on the runtime? For example, one can't find Chrome, Safari or Node TextDecoder and port 90% of the code over? If one wanted to do that, JSI or a C++ TurboModule would be more appropriate?

[tmikov]

I take it the Hermes builtins don't use similar code to the browser runtimes because they're implemented on the engine rather than on the runtime? For example, one can't find Chrome, Safari or Node TextDecoder and port 90% of the code over?

You can't just take an implementation written for JSC in Safari and just move it into Chrome with v8. These are different environments with different APIs. So is Hermes. Porting runtime code between engines is certainly possible, bit is not trivial. Special attention has to be paid to the overhead of data marshaling between JS and C++.

If one wanted to do that, JSI or a C++ TurboModule would be more appropriate?

JSI and TurboModule are the same thing, TurboModule just provides some higher level convenience. Neither is particularly convenient for porting existing code from Chrome or NodeJS, but they are the only option currently. Raw JSI offers more flexibility.

[shamilovtim]

@tmikov I ported some Node Crypto to JSI and it was pretty straightforward. Although every line was rewritten by hand there was almost no custom logic necessary, most of the variables and the macros were the same, and the conditionals were all the same. When I looked at Chrome's implementation of WebCrypto it also looked like it could be rewritten in JSI pretty straightforwardly. I was curious if maybe some of that was possible with Hermes but it definitely sounds like when it's implemented on the engine it's a completely different situation.

[tmikov]

@shamilovtim if the overhead of JSI is not a problem, then I believe using JSI is the best option for now.