With ReactNative, the controls are all native, JavaScript is just there for orchestration, so it is far different than HTML 5, given the browser doesn't give you the same array of native components to use.
That's less accurate than my original post, especially given I was commenting on the performance trade-offs of RN's architecture. I highly recommend watching this official video about the internals in order to gain more of an understanding:
In short, there aren't too many interpreted languages that don't rely on "native bridges" for things like UI and access to system libraries, but I wouldn't call desktop GUI frameworks for non-native languages like Java Swing or C# WinForms "native" even though they also use what you call "native components."
On the other hand, I would consider iOS Objective-C/Swift, Android NDK, and MFC/QT/GTK+ in compiled languages like C++, Rust, etc. to be truly "native" (but not Android Java, of course).
React "Native" is still very much interpreted code (if anything, RN is a different kind of "browser" that runs JS code -- yes, the JS that runs in browsers still has the same "orchestration" role that you've described from an architecture standpoint).
I haven't been following React closely but this reminded me of a package called SWT that is used as the underpinning for Eclipse (https://www.eclipse.org/swt/). In the case of SWT, the underlying widgets are platform native but the orchestration is in Java. SWT was used to build a few desktop apps but mostly it seems to have been forgotten now. It left me skeptical of these kinds of thin UI layers.
I'm not an expert, but I think that there is a different approach between React / React Native and SWT. SWT created layer of abstractions - when using their apis you were writing code once - and it was supposed to work the same way on all supported platforms. However React / React Native just use the same React paradigm to rendering controls, but the controls themselves are specific to the platforms. What you share is all the code that is not views, but views themselves are separate codes.
I've been working pretty extensively with RN these days.
Almost always, the code is the same (doesn't HAVE to be though but almost always is), and even the views are the same (barring some exceptions where Android and iOS have completely different design language requiring you to customize things at the code level using platform conditionals in the same source file).
https://www.youtube.com/watch?v=8N4f4h6SThc
In short, there aren't too many interpreted languages that don't rely on "native bridges" for things like UI and access to system libraries, but I wouldn't call desktop GUI frameworks for non-native languages like Java Swing or C# WinForms "native" even though they also use what you call "native components."
On the other hand, I would consider iOS Objective-C/Swift, Android NDK, and MFC/QT/GTK+ in compiled languages like C++, Rust, etc. to be truly "native" (but not Android Java, of course).
React "Native" is still very much interpreted code (if anything, RN is a different kind of "browser" that runs JS code -- yes, the JS that runs in browsers still has the same "orchestration" role that you've described from an architecture standpoint).