3 ms·

The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data be

The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. You can't code it like a web app where you just replace one large node tree with another if you want it to be instant, you have to mount both and keep one invisible, either using a navigation library or custom code. This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge. The extra latency for a layout change is most noticeable if it's an animation hence why you should use native animations not JS polling animations. I agree the Animations API is not as easy as CSS. If you want to do complicated stuff you need a lot of experience with it. This is one of the major hurdles for new RN devs. Its possible to get good performance our of it, better than mobile web UI, you just need to have some experience with what costs and what doesn't.

LinguaBrowse 6y ago
> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript. In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated. https://github.com/shirakaba/react-nativescript https://github.com/shirakaba/react-nativescript https://react-nativescript.netlify.com/ https://react-nativescript.netlify.com/
- partyboat1586 6y ago
  Sweet, no more bridge bandwidth issues. I'll check it out.
- iainmerrick 6y ago
  Sounds great! After using RN for a while, that’s exactly how I think it should have been designed in the first place. Good luck!
iainmerrick 6y ago
If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself. This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge. Even if they were to stick with the multithreaded architecture, it should be possible to build a layout structure in the background thread and just hand ownership over to the UI thread. I believe the RN team are working on doing this with their new Hermes runtime (sharing objects directly rather than marshalling them into and out of the JS engine), so that ought to help a bit. But I really think the threading model is just wrong-headed in the first place. Its possible to get good performance our of it, better than mobile web UI Is there a case study or even just an example that demonstrates that? I'm skeptical. Mobile browsers are very fast these days, so there's no obvious reason why RN should necessarily be faster. I suppose RN might have an edge if you're making extensive use of native code. But then calling native code from RN is very laborious, so RN doesn't exactly pull its own weight in that scenario.
- partyboat1586 6y ago
  There are no benchmarks I know of, it's accepted wisdom that React Native is faster than mobile web even when not optimised and comes close to native when optimised. That has always seemed self evident to me but maybe it's time someone did some benchmarks. I think the reason RN is faster is because mobile browsers have to support decades of crufty CSS in their layout engines while native layout engines are much more lean and ripe for optimisation. React Native uses Yoga layout engine so there may actually be benchmarks available on that.

LinguaBrowse 6y ago

> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript. In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated. https://github.com/shirakaba/react-nativescript https://github.com/shirakaba/react-nativescript https://react-nativescript.netlify.com/ https://react-nativescript.netlify.com/

partyboat1586 6y ago
Sweet, no more bridge bandwidth issues. I'll check it out.
iainmerrick 6y ago
Sounds great! After using RN for a while, that’s exactly how I think it should have been designed in the first place. Good luck!

iainmerrick 6y ago

If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself. This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge. Even if they were to stick with the multithreaded architecture, it should be possible to build a layout structure in the background thread and just hand ownership over to the UI thread. I believe the RN team are working on doing this with their new Hermes runtime (sharing objects directly rather than marshalling them into and out of the JS engine), so that ought to help a bit. But I really think the threading model is just wrong-headed in the first place. Its possible to get good performance our of it, better than mobile web UI Is there a case study or even just an example that demonstrates that? I'm skeptical. Mobile browsers are very fast these days, so there's no obvious reason why RN should necessarily be faster. I suppose RN might have an edge if you're making extensive use of native code. But then calling native code from RN is very laborious, so RN doesn't exactly pull its own weight in that scenario.

partyboat1586 6y ago
There are no benchmarks I know of, it's accepted wisdom that React Native is faster than mobile web even when not optimised and comes close to native when optimised. That has always seemed self evident to me but maybe it's time someone did some benchmarks. I think the reason RN is faster is because mobile browsers have to support decades of crufty CSS in their layout engines while native layout engines are much more lean and ripe for optimisation. React Native uses Yoga layout engine so there may actually be benchmarks available on that.