4 ms·

React Native's basic navigator component is non-native and implemented in a way that has fundamental performance problems. There is also a native navigator comp

by mbrock 11y ago

React Native's basic navigator component is non-native and implemented in a way that has fundamental performance problems. There is also a native navigator component for iOS, but it's buggy and unmaintained to the point of being unusable. The list view also has issues. See e.g. issues like these: https://github.com/facebook/react-native/issues/3452 https://github.com/facebook/react-native/issues/3452 https://github.com/facebook/react-native/issues/567 https://github.com/facebook/react-native/issues/567 https://github.com/facebook/react-native/issues/3049 https://github.com/facebook/react-native/issues/3049 https://github.com/facebook/react-native/issues/2569 https://github.com/facebook/react-native/issues/2569 The marketing claim on their main web page that "React Native apps are naturally fluid and responsive" needs qualification. These pages are essential reading for anyone considering using React Native for a project with deadlines: https://facebook.github.io/react-native/docs/performance.html https://facebook.github.io/react-native/docs/performance.htm... "Many people have noticed that performance of NavigatorIOS is better out of the box than Navigator. The reason for this is that the animations for the transitions are done entirely on the main thread, and so they are not interrupted by frame drops on the JavaScript thread. (Read about why you should probably use Navigator anyways.)" "... As mentioned above, Navigator animations are controlled by the JavaScript thread. Imagine the "push from right" scene transition: each frame, the new scene is moved from the right to left, starting offscreen (let's say at an x-offset of 320) and ultimately settling when the scene sits at an x-offset of 0. Each frame during this transition, the JavaScript thread needs to send a new x-offset to the main thread. If the JavaScript thread is locked up, it cannot do this and so no update occurs on that frame and the animation stutters." https://facebook.github.io/react-native/docs/navigator-comparison.html https://facebook.github.io/react-native/docs/navigator-compa... Regarding the native-styled and higher-performing NavigatorIOS: "Development belongs to open-source community - not used by the React Native team on their apps. A result of this is that there is currently a backlog of unresolved bugs, nobody who uses this has stepped up to take ownership for it yet." Disclaimer: this comment is written by a consultant undergoing high levels of frustration and may have traces of FUD. If React Native works well for you, I would love to hear about it. Edit: I was really hoping to do some good work on the app today. The frustrating problem this time is that the devtools are entirely broken due to a commit made back in September. https://github.com/facebook/react-devtools/issues/229 https://github.com/facebook/react-devtools/issues/229 "I don't know how to fix this. I now remember that this is why we didn't merge that RN pull request originally." UGH. Shoot me.

andy_ppp 11y ago
>>> React Native's basic navigator is non-native and implemented in a way that has fundamental performance problems. - just use the InteractionsManager - Navigator works well enough on all the Facebook apps and Paper etc. yes agreed about the NavigatorIOS - it doesn't work and I complained bitterly somewhere on github about that. - You probably aren't coming from the web where I think most people know that if you are making requests in the background and doing too much stuff inside of requestAnimationFrame your performance will be bad. - Maybe you should move the Javascript that is causing performance slowdowns into Native code if it's that complicated then it'll run on the different thread? I think if you come from an app background it's probably easier to expect better performance. - I hope you are testing performance in the Release build mode in xcode, it needs to be on for loads of optimisations to be made. - I've found performance acceptable so far and excellent when you use actual Native things.
- mbrock 11y ago
  Thanks. Yeah, I'm in the process of putting in spinners conditioned by InteractionManager. I'd prefer rendering to be fast enough by default, but there's no free lunch. I am coming from the web, where I usually don't have to think about animation frames when implementing basic functionality. React Native's way of implementing navigation animations with repeated timer calls between JavaScript and iOS makes this a problem. The performance slowdown is caused by lists, texts, and images. I am not doing any animations or fancy interactions. Moreover, we chose React Native exactly because it would let us use JavaScript for these things, since that integrates with our web app "isomorphically." I'm hopeful that with release build mode and InteractionManager-based spinners, I'll be able to get acceptable performance. I'm just a little surprised at how many performance gotchas I've run into.
  - andy_ppp 11y ago
    Yeah, let me know how you get on with a release build - we've had a few issues that went away with that on. How big is your app, ours seems fine with normal usage on a real device... Guess it does depend on what you are doing.

by mbrock 11y ago

andy_ppp 11y ago

>>> React Native's basic navigator is non-native and implemented in a way that has fundamental performance problems. - just use the InteractionsManager - Navigator works well enough on all the Facebook apps and Paper etc. yes agreed about the NavigatorIOS - it doesn't work and I complained bitterly somewhere on github about that. - You probably aren't coming from the web where I think most people know that if you are making requests in the background and doing too much stuff inside of requestAnimationFrame your performance will be bad. - Maybe you should move the Javascript that is causing performance slowdowns into Native code if it's that complicated then it'll run on the different thread? I think if you come from an app background it's probably easier to expect better performance. - I hope you are testing performance in the Release build mode in xcode, it needs to be on for loads of optimisations to be made. - I've found performance acceptable so far and excellent when you use actual Native things.

mbrock 11y ago
Thanks. Yeah, I'm in the process of putting in spinners conditioned by InteractionManager. I'd prefer rendering to be fast enough by default, but there's no free lunch. I am coming from the web, where I usually don't have to think about animation frames when implementing basic functionality. React Native's way of implementing navigation animations with repeated timer calls between JavaScript and iOS makes this a problem. The performance slowdown is caused by lists, texts, and images. I am not doing any animations or fancy interactions. Moreover, we chose React Native exactly because it would let us use JavaScript for these things, since that integrates with our web app "isomorphically." I'm hopeful that with release build mode and InteractionManager-based spinners, I'll be able to get acceptable performance. I'm just a little surprised at how many performance gotchas I've run into.
- andy_ppp 11y ago
  Yeah, let me know how you get on with a release build - we've had a few issues that went away with that on. How big is your app, ours seems fine with normal usage on a real device... Guess it does depend on what you are doing.