React Native: Summing up
I’ve been using React Native for 6 months, and it seems like the time to make some conclusions has come. But small warning comes first: I’ve been using React Native mostly in combination with ClojureScript (which is so cool and sexy), Reagent and re-natal, that’s why if you use JavaScript (and Flux and Redux and whatever) the experience may be different.
In addition, I have no experience in native iOS development, but I spent my best years creating Android apps. That’s why this post will be more like a comparison of React Native development and Java Android development.
Before reading this article you can also read my first article about React Native + ClojureScript here.
Pros
No more adapters. It may sound obvious, but most of us hate doing stupid and routine work. Writing adapters is one simple example of this work. The good news is you don’t need to do anything like that if you use React Native! Instead of adapters you just need to write several components and create one multimethod to dispatch on your “view type”. This is how it may look:
No more models for SQL entities. One more thing Android programmers usually hate is describing models for data structures app receives in JSON format. But wait, JSON is just a JavaScript object and it may be easily converted to ClojureScript map.
Users may also use Transit instead of converting JS objects to ClojureScript maps. It will make things much simplier:
What about saving objects to an internal database? Two lines of code. And, just as a reminder, it will work on both Android and iOS.
Ability to update your app in background without AppStore or Google Play. A little hacky, but if you want it, you can. It is possible because your application code is actually one .bundle file. And this file may be easily replaced in runtime.
It is easy to write your library. The process of creating JS wrappers is easy and well-documented (here and here), and writing a good wrapper for native Android or iOS library usually takes 2 or 3 hours. By the way, a couple of days ago I created my own library for photo zooming, which you may use as an example.
Reactive by definition. It means that usually you don’t need to care about activity lifecycle, fragments, callbacks, etc. The only thing you need to care about is the relationship between you data and UI.
Live Reload. Well, it is possible to use this feature even for native Android development, but in this case you need to reload your app from time to time not only when you add a new library (it is the only case when you need to reload your app when using React Native), but also when you edit your AndroidManifest.xml or create database migrations.
Flexbox! Yes, with React Native you combine your layouts the same way as web developers do. Forget about all those crazy XML layouts.
Cons
It is in alpha/beta stage. Actually, it is the only problem, because everything else should be fixed in the nearest future. Because of the current React Native status, sometimes new releases break your application. You will also probably see lots of deprecations all the time, and you will be fixing someone’s libraries to make them support new versions of React Native.
Debugging is difficult. Most of the time you will be debugging using console.log() method and most of the crash descriptions will be non-descriptive at all.
Most 3rd-party libraries are crappy. Sometimes it is difficult to find a library that completely suits your needs and sometimes it’s easy to find library that doesn’t really do anything — it just combines two components from standard library the most ugly way possible.
Lists performance is bad. It is because lists in React Native are not exacly lists. ListViews are more like ScrollViews that just try to mimic real lists. React Native lists also manage memory by its own way, and don’t use all these optimizations RecyclerView has. There are some strange techniques that allow to increase React Native list performance, but in several cases the performance will suck anyway.
No activities and native activity transitions. One more obvious thing — an application constists of one Activity. And for this reason it is impossible for your apps to look completely native — you will see non-native transitions anyway.
Well. Do I need to use it?
Yes! React Native is cool and, despite of all its weaknesses, it improves your experience and make you love the code you write. It also makes mobile development fun again.
But in some cases using React Native will make you suffer. If you need to perform image or audio processing or use OpenGL or NDK, go native. In this case you don’t need to use neither React Native nor any other cross-platform development toolkit. For now React Native suites well for REST-client-like applications and thus is a bit limited. But it is, actually, your chance to participate in open-source development and make our future brighter :)
