To summarize this article: The author really enjoyed using React Native up until he hit some performance issues related to loading large images on certain versions of Android.<p>He doesn't go into what specifically the performance issues were, any techniques he used to profile his app, what third party libraries he tired or anything.<p>Performance issues happen all the time with native apps that don't use React Native. Optimizing is a core part of what a software engineer does. Giving up on weeks of learning without a good reason seems like a poor choice to me.<p>As it so happen's I have been working with a colleague of mine who just fixed a React Native performance issue relating to images on Android on older devices. The author might want to check out the following article:<p><a href="https://facebook.github.io/react-native/docs/performance.html#moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps" rel="nofollow">https://facebook.github.io/react-native/docs/performance.htm...</a><p>Our particular issue was solved by the following:<p>"This is especially true when you have text with a transparent background positioned on top of an image, or any other situation where alpha compositing would be required to re-draw the view on each frame. You will find that enabling shouldRasterizeIOS or renderToHardwareTextureAndroid can help with this significantly."<p>Apart from the above, this article is pretty shallow, which is sad because I would love to read a good article on React Native's performance. Perhaps I will write one if people are interested.
I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though.<p>This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painless. The UI metaphor is fantastic, the tooling is superb, the editor support is there, the community is growing. It's a great place to be.<p>It's not without it's warts though. From my experience, the real problems stem from the 3rd party native modules. It's not even their fault, the platform is just moving so fast. As recently as the 0.40 release, every native module out there was broken on iOS for a short period of time. I was the first to submit PR's to two fairly widely used ones, and that was multiple days after the release. On this point, I believe this is more indicative of a community that generally doesn't upgrade their projects right away- a combination of painful prior experience and a deep seeded distaste of having to re-release their app on all stores as you can leverage a tool like Microsoft Code Push to change the bundle as long as it is compatible with the native shell.<p>Of the two RN projects I'm working, both have at least one dependency pinned to a Github fork I have of a project, waiting for my patches to be released. This sounds worse than it is, as the majority of native modules are hilariously small and easy to modify, but it still is worth mentioning as a point of friction today. As the community grows, I expect this will diminish.
I've done some work with react native, and have definitely been disappointed by the poor quality of many third party libraries that are not supported by Facebook.<p>This is a big opportunity for those who might wish to make a name for themselves by developing some top quality open source components, but I also think Facebook should do a bit more to make using the phone's core features in a very high quality way as easy as possible. Things like the camera, audio recording, video, etc., are handled only via third party libraries.<p>The third party open source work is improving, and I'm grateful it exists, but much of it lacks contributors. Many have large lists of unresolved issues on github.<p>It would be very smart choice for Facebook to put a dozen or so developers on the task of submitting high quality PRs for the top 20 open source non-facebook libraries.
I searched for the holy grail of cross-platform goodness like a fool for years. I now have my first native UI android application on google play and I don't regret the decision. I made a prototype and then optimized it in ways I wasn't able to do in html or react-native. (try downloading and caching pictures rendered in a listview asynchronously while keeping the scroll smooth)<p>I now don't have an iOS version, but in my opinion having a finished product that is already gaining traction makes up for the lost time of learning to make the same thing for iOS.
My next foray into mobile is going to be with this-<p><a href="https://www.nativescript.org/" rel="nofollow">https://www.nativescript.org/</a><p>Digging through the api it just looks much more capable in directly calling android instead of abstracted cross platform blobs.
Sounds like a good opportunity to build some performance-tuning muscle :)<p>Whether using RN or java, you'll want to know how to debug memory/performance issues on Android - they're mostly unavoidable on mobile devices!<p>(And maybe you can file some issues against React Native, too, which would be great and help the platform)
It'd be nice with React Native was actually "native" and not just a JS interpreter (really not that much different than HTML5 running in a browser). No wonder there are performance issues.
If you already know how to do the image related task in Native Android, you could spike a test project and verify that it's performant on the smaller devices and the problem could be attributed to React Native alone. Then it's a matter of porting the high level API to JS.<p>Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having React Native made it worse.
What do you all think of Cordova? Do the author's comments apply there also? Does it crash from using too much memory after a while of loading objects? And does it make things not work on older devices and platforms making it a dealbreaker for anyone?
I posted a follow-up to this story talking about further explorations based on the feedback I got from your comments.<p><a href="https://kelvinpompey.me/tempted-to-abandon-react-native-for-native-android-part-2/" rel="nofollow">https://kelvinpompey.me/tempted-to-abandon-react-native-for-...</a>