Consistent cross platform: This is actually the one thats probably most difficult with react-native. Since unlike electron or Flutter, React-Native uses native UI for each platform. This means you can achieve full parity with native apps in terms of the UI. But all the platforms have different capabilities so since react-native can take full advantage of all the platforms, and isn't lowest common denominator, there are differences between the rendering / support across multiple platforms.
Can the native UI framework do multiple windows? - Then React-Native can do multiple windows.
Rendering to a windows that isn't owned by the framework is what React-Native refers to as Brownfield apps. This is absolutely supported. For instance, Microsoft Office is using React-Native for some parts of their UI in Android, iOS, Windows and macOS. And the Office window is not created or owned by react-native.
For that matter: Sciter supports use of native platform (or custom) native windows or widgets. For different reasons an combinations. I saw cases when even Qt widgets were used as DOM elements in Sciter controlled main window. So you can get best of two worlds - flexibility of HTML/CSS (rendering, layout managers) and native UI behavior and look.
We have done some internal tests of Hermes on a RN experience within Microsoft Office on Android.
Currently we use V8 with bytecode caching on Android, since it provided better startup performance than the JSC engine that normally ships within RN. So the baseline is likely already faster than stock RN.
V8 time to interaction: 1.4s
Hermes time to interaction: 1.1s
We have done similar experiments on a full react-native-windows application, replacing the Chakra JS engine (also already with bytecode so faster than stock RN) with Hermes and had app boot time on a low end device go from 3.8s to 3.1s.
It's a pity the Proxy is not supported
mobx is really much nicer approach to state management and usually, apps using mobx are much faster - simply because implementing shouldComponentUpdate properly is hard
Hermes compiles JS ahead of time to bytecode. The VM takes bytecode in as input, not source code. The ES5 vs. ES6 distinction doesn't matter as much as in other engines where the runtime takes source code as input, and as a result has to pay the more expensive ES6 parsing cost at runtime.
