How is ReactNative's CodeGen and JSI fundamentally different from NativeScript's metadata service and type marshalling?

[shudv]

From my understanding, the aim for both mechanisms is to enable the main application thread to synchronously call JS code from native code and vice versa. What are the fundamental differences in both mechanisms? Is one more performant than the other?

[shirakaba]

I'll summarise what I know about the React Native approach just to get everyone on the same page. For the NativeScript side of things, I'll write up my working understanding, but any experts are welcome to correct details!

Marshalling in React Native

The old way: a relatively simple JSON bridge

In React Native, the old way of communicating was via a JSON bridge. The native side would accept JSON messages from the JS side, and vice versa, and you could set up each side to react to those messages however you'd like. The limitation being that only JSON-serialisable data types could be sent over the bridge.

The new way: direct marshalling via JSI

The new way is via the JavaScript Interface (JSI). For each different JS engine (JSC, V8, Hermes, QuickJS, and more), Meta or Microsoft will likely have implemented an interface (likely using C++) that tells the JS engine how to handle native data types (HostObjects) internally. Here's the one for JSC, for example. Then, from each different platform (iOS, Android, etc.), one can use the appropriate language (typically Obj-C++ for iOS, and Java with JNI for Android) to call upon React Native's generic JSI APIs. Those generic JSI API calls then hand off to the JS engine-specific implementation to handle the native data types.

So React Native JSI allows a user to manually set up individual bindings to APIs of interest, by writing some native code for each platform. Codegen simplifies this process by having you write out the shape of the API you want in TypeScript and then filling in all the interfaces for you, but you'd still have to write the implementation. The main friction is that there is no official documentation on either Codegen, JSI, or Turbomodules yet. On that note, Turbomodules is, to my understanding, just JSI written by a particular convention to avoid as much as possible rewriting the same thing for each different target platform. By having this conventional shape, it may be that it can benefit from being loaded in a different order to JSI, but I'm not sure (just something I heard on Twitter). As I said, lack of documentation makes it all a bit mysterious for now.

NativeScript

EDIT: After writing this section, I did a deep-dive to see NativeScript's JS->native bindings work at the low level, which you can read here. I'll keep the below high-level explanation as I originally wrote it, however.

This section is all just to my understanding. I defer to anyone more expert in this!

Upon building your app, NativeScript updates its metadata bindings so that essentially every API in your app with a public header gets an equivalent JavaScript binding generated for it (and equivalent TypeScript types can also be generated). There are some pros and cons to this.

Upsides

You can access all native APIs directly using JS. To reiterate, in React Native JSI, you'd manually write some bindings in Obj-C++ and Java (assuming just an iOS and Android project) for a small number of APIs of interest and then from JS you could call those bindings. In NativeScript, all bindings for the entire platform's SDK and your userland native code are already established and ready to go, and again, come with equivalent TypeScript typings.

This means that, in NativeScript, you don't have to wrestle with native code files, pointer ownership, garbage collection, writing TypeScript types (though yes, not a huge concern once Codegen becomes documented) and whatnot. You can write a whole app just using TS/JS files; if there are any gaps in the NativeScript Core APIs, you can handle it in userland rather than having to fork NativeScript Core to add the new APIs.

Of course, if you do ever want to write any native code directly using a native language like Obj-C, then you can still make native modules for that just fine in NativeScript.

Downsides

Loading in metadata to bind all platform APIs will have some implications for app size and startup time, but I don't know how much (to be clear, it's an acceptable level, though naturally the weight is non-zero). Fortunately, it is possible to filter down the bound metadata to just the SDKs of interest using metadata filtering.

Another downside of accessing native APIs entirely from JavaScript is that you may miss some native IDE assistance. A good amount of this is mitigated (e.g. @deprecated comments in the TypeScript typings, and typings for each different level of the Android SDK or version of the iOS SDK), but inevitably some subtle assistance may be missing. From my perspective, the type-checking of code in TypeScript is so much faster than the edit-time compilation of Obj-C or Swift that it's a fair tradeoff.

Conclusion

I suspect that the speed of data marshalling is comparable between React Native JSI and NativeScript. So I feel the main difference between the two is whether the bindings need to be written manually (React Native) or are generated automatically (NativeScript).

[shudv]

So my hunch was not misplaced. If it's the same underlying tech - what makes React Native (new architecture) and NativeScript different is how they deal with rendering. I don't see why there there need to be 2 frameworks doing the exact same thing (JS -> native bindings) in slightly different ways. We can aim for having a cohesive performant (JS->Native) binding mechanism and then the UI tech can be implemented on top of that independently - React/Vue/Angular/Svelte.

[shirakaba]

what makes React Native (new architecture) and NativeScript different is how they deal with rendering.

There are a few other differences.

NativeScript conventionally runs its JS process on the main (UI) thread, while React Native conventionally runs it on a separate thread. This is a tradeoff. While separating these things into threads reduces the potential to block the UI thread during heavy/repetitive tasks, it makes interacting with the UI (e.g. reacting to autocorrect in a text view, or constraining a layout based on the measurement of a native UI element) a lot more fiddly. Time-critical aspects like gestures and animation can pose particular problems with with this separation. From my perspective, as web browsers can generally handle logic and UI sharing the same thread, we needn't worry about NativeScript apps doing the same.

I don't see why there there need to be 2 frameworks doing the exact same thing (JS -> native bindings) in slightly different ways.

My impression, gathered from other React Native users, is that most people actually want to spend as little time as possible grappling with native APIs. Ideally a core API or plugin would exist that allows them to never have to read up on native APIs in the first place. The Expo ecosystem is the embodiment of sticking with well-designed cross-platform abstractions (it's a really, really good SDK). While NativeScript does have a rich library of cross-platform abstractions and ecosystem of plugins (A.K.A. native modules) just like React Native, its philosophy is more one of embracing the full capabilities of the platform SDKs, and so it really depends on what kind of developer you are.

We can aim for having a cohesive performant (JS->Native) binding mechanism and then the UI tech can be implemented on top of that independently - React/Vue/Angular/Svelte.

This is exactly why I love how NativeScript is imperative, and I think React Native should never have been coupled to React in the first place. I was very excited to hear some statements some years back from the React Native core team that they were thinking of decoupling the two, but it appears that they've not pursued that plan since first mentioning it.

I did actually attempt to produce a "Reactless Native" framework, react-native-in-nativescript, by seeing if I could extract the imperative elements out of React Native and drive them using NativeScript. I made some progress (see my tweet where I use NativeScript to render some React Native primitive views to screen), but hit a roadblock because I couldn't figure out the relationship between RCTViewManager, RCTUIManager, and RCTView (etc.) due to their lack of documentation. Basically, I couldn't figure out where the React stopped and the UI elements began.

One thing is for sure, though – by combining the best of NativeScript and React Native, an even more brilliant framework could be created!

[farfromrefug]

@shirakaba great explanation. I also want to point out that the Dev env of RN and N are very different. They use very different approaches to how native plugins are written. N does not need the native code to have any dependency on any N headers/framework. It does not enforce any "layout". There a big and nice consequence to this, any natively implemented plugin for N can be used in native iOS/Android app. And the opposite is also pretty cool, using Android/iOS native libs does not require any wrapping in N.
I think it is part of what makes N and RN very different frameworks with different targets.
And I am not even talking about design choices made by RN compared to N. Like the choices made for FlastListView in RN. They decided to move away from the native way while N relies completely on the platform native APIs.

[shudv]

NativeScript conventionally runs its JS process on the main (UI) thread, while React Native conventionally runs it on a separate thread. This is a tradeoff. While separating these things into threads reduces the potential to block the UI thread during heavy/repetitive tasks, it makes interacting with the UI (e.g. reacting to autocorrect in a text view, or constraining a layout based on the measurement of a native UI element) a lot more fiddly. Time-critical aspects like gestures and animation can pose particular problems with with this separation. From my perspective, as web browsers can generally handle logic and UI sharing the same thread, we needn't worry about NativeScript apps doing the same.

More than that - not having a separate thread for heavier tasks by default in NativeScript does not mean you can't go ahead and offload heavy stuff to a background worker. In NS, you always have the native APIs available to do whatever you want to do to manage your workload efficiently. The sentiment that I read in the community when it comes to comparing RN and NS is that - RN is somehow magically "faster" because it is multithreaded. I never understood how that made any sense.

My impression, gathered from other React Native users, is that most people actually want to spend as little time as possible grappling with native APIs. Ideally a core API or plugin would exist that allows them to never have to read up on native APIs in the first place. The Expo ecosystem is the embodiment of sticking with well-designed cross-platform abstractions (it's a really, really good SDK). While NativeScript does have a rich library of cross-platform abstractions and ecosystem of plugins (A.K.A. native modules) just like React Native, its philosophy is more one of embracing the full capabilities of the platform SDKs, and so it really depends on what kind of developer you are.

More than the kind of developer, the exact requirements at hand dictate things in most scenarios. Personal experimental projects which can afford a lot of agility can decide to just jump on to a set of preset abstractions set by someone else and hope that those abstractions would suffice for their short to medium term needs. But when you are trying to take a long term decision, you wouldn't want to lose all control and flexibility to a framework right away (RN' FlatListView implementation choice pointed out by @farfromrefug is exactly the kind of thing I am talking about). This is one of the main reasons I try to stay away from Flutter for enterprise grade projects, just because of the amount of control you lose to that framework. NativeScript on the other hardly "imposes" anything on you, which I find really really attractive.

This is exactly why I love how NativeScript is imperative, and I think React Native should never have been coupled to React in the first place. I was very excited to hear some statements some years back from the React Native core team that they were thinking of decoupling the two, but it appears that they've not pursued that plan since first mentioning it.

+1 to that. React is not fundamental to the cross-platform problem in any way. It's just another UI framework. In fact, it wouldn't be wrong to say the React Native's popularity has been greatly influenced by React's popularity. And hence, in any comparison between NS and RN, NS just loses out against the dazzle of huge community that RN enjoys. But we should note that it's probably "React" that is defeating NS and not "React Native" itself.

I did actually attempt to produce a "Reactless Native" framework, react-native-in-nativescript, by seeing if I could extract the imperative elements out of React Native and drive them using NativeScript. I made some progress (see my tweet where I use NativeScript to render some React Native primitive views to screen), but hit a roadblock because I couldn't figure out the relationship between RCTViewManager, RCTUIManager, and RCTView (etc.) due to their lack of documentation. Basically, I couldn't figure out where the React stopped and the UI elements began.

I haven't worked with React enough to comment on it. But based on my limited experience with it and other frameworks, I don't see why it is revolutionary as compared to any other UI framework like Svelte, Angular or Vue. React should just be placed alongside all others and developers should make a choice based on their needs.

One thing is for sure, though – by combining the best of NativeScript and React Native, an even more brilliant framework could be created!

Maybe I have a different way to look at things here - I see two different problems that can (and should) have independent solutions. 1 - Capability to share business logic that can depend on native platform capabilities and 2 - Capability to share UI components. RN and NS attempts to solve both. RN and NS solve #1 differently but with RN's new architecture they seem to converging to a very similar place. For #2, you are bound to React in React Native whereas NS supports choosing any UI framework that you want. Based on this, I really don't see a "meaningful co-existence". In an ideal world, they should align and merge.

[NathanWalker]

The NativeScript community is always an open door; capable and willing to work with any other community to enhance the JavaScript ecosystem. It is my personal hope that React Native and NativeScript can benefit from each other by more collaboration.