Tempted to Abandon React Native for Native Android

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.

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.

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.

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:

https://facebook.github.io/react-native/docs/performance.htm...

Our particular issue was solved by the following:

"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."

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.

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.

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.

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.

Yep, exactly my experience. I love React Native but if your not used to the Javascript style of million's dependencies your in for a world of pain.

It's critical to spend more time vetting third party React Native/Javascript libraries as the quality level varies way more than with native libraries.

As a native developer I hadn't spent a lot of time working deeply with npm. One thing to be careful about when saving packages to your project is the use of ^ versus ~. See:

http://stackoverflow.com/questions/22343224/whats-the-differ...

" the tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but will miss 1.3.0.

The caret, on the other hand, is more relaxed. It will update you to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0."

Considering the volatility of some third party Javascript libraries, this can cause quite a bit of pain.

It's worth doing the following in your home directory add save-prefix=~ to your .npmrc and all npm install's in the future will automatically add ~ instead of ^

I analysed react-native's performance issues with images and out-of-memory-errors a while back.

Their (and their image library Fresco's) problem is that they make heavy use of object-finalizers, which is an error in Java and especially Android.

I reported a couple of bugs, but got dismissed:

https://github.com/facebook/react-native/issues/8711

https://github.com/facebook/react-native/issues/8780

https://github.com/facebook/fresco/issues/1363

I found this rather frustrating.

I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C. Again, a bugreport, again, dismissed.

https://github.com/facebook/react-native/issues/10504

It seems that Facebook's Java programmers don't know Java very well.

Just a wild guess - you said opening for processing. Depending on what you're doing with the file and how you're opening it the whole data get's passed over the bridge resulting in some catastrophic memory allocations. I would recommend tapping into the bridge communication and start checking if everything stays where it should. Some picker modules tend to send base64 encoded file beside the URL.