3 ms·

React native code re-use is possible just not in the way people imagined. You can reuse your Redux code, you can reuse higher order components you just can't re

React native code re-use is possible just not in the way people imagined. You can reuse your Redux code, you can reuse higher order components you just can't reuse the atomic UI elements. React native performance is good too it just doesn't come for free. You need to know how to do native animations and you need to do late binding and all the other performance optimisations you should be doing with React anyway. The only thing that lets React Native down is the tooling. I've had the debugger repeatedly push stale code on refreshes, the source mapping is atrocious and sometimes the network debugger just refuses to work. Also sometimes the app fails to load and you need to reload the app and or restart the debugger and or restart the packager in the right order.

iainmerrick 6y ago
Is React Native performance really good? Compared to what? I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI. I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components. Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)
- karatestomp 6y ago
  > Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.) My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.
  - iainmerrick 6y ago
    Yes, agreed! The tools are starting to get fairly good on Android. There’s a lot to like about Android Studio. But the actual platform APIs are still a mess.
- partyboat1586 6y ago
  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!
- LinguaBrowse 6y ago
  > I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components. Totally agreed. I’m working on an alternative to React Native that addresses exactly this: 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 to begin with. https://github.com/shirakaba/react-nativescript https://github.com/shirakaba/react-nativescript https://react-nativescript.netlify.com/ https://react-nativescript.netlify.com/

iainmerrick 6y ago

Is React Native performance really good? Compared to what? I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI. I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components. Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)

karatestomp 6y ago
> Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.) My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.
- iainmerrick 6y ago
  Yes, agreed! The tools are starting to get fairly good on Android. There’s a lot to like about Android Studio. But the actual platform APIs are still a mess.
partyboat1586 6y ago
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!
LinguaBrowse 6y ago
> I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components. Totally agreed. I’m working on an alternative to React Native that addresses exactly this: 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 to begin with. https://github.com/shirakaba/react-nativescript https://github.com/shirakaba/react-nativescript https://react-nativescript.netlify.com/ https://react-nativescript.netlify.com/