Velocity, Performance, Scaling - 3 Questions I ask before I choose React-Native over Native
Technologies used for mobile apps development can pretty much be divided into 3 major categories:
- Native - Java/Kotlin for Android and Objective-C and Swift for iOS
- Hybrid - Single code base in one language
- WebView based - Loads HTML + CSS + JavaScript pages
I’ll mainly focus on Hybrid, and more specifically on React Native.
For the past 3 years, I’ve been using React Native for most of my mobile applications needs. Prior to that, I was all about native. In between, I published a couple of native apps (Java for Android and Objective-C for iOS) and even had thought about what I’d like to do next and what tech I’d use.
When I think of mobile applications technologies, I think of these topics:
- Velocity - How fast is the development?
- Performance - How smooth the app will be?
- Scaling - Can I grow to 10x developers and features?
Velocity
Writing code once instead of twice is a key velocity factor when you pick cross-platform technology.
This means that the mobile development team can be half size. This also means that each team member can do any task, without any relations or dependency on his background or platform.
React Native covers most iOS and Android APIs, which in most cases, eliminates having to deal with platform-specific code and logic. And if we will have something missing, we will probably find it in one of the open sources libraries with are offered and supported by the incredibly friendly React Native community. I strongly suggest you dive into it, it’s a well-established community and very helpful.
Usually, we have to deal with bugs, even when we sincerely think that our code is properly written and, in our hearts, are sure that is also functional. In this case, we write the code once, meaning we decrease the number of bug fixes we have to cover, rather than fixing the same bug twice, once in each platform.
React Native takes all the JavaScript code and bundles it into a single bundle file. Technologies, like Code Push, even offer to load this bundle file remotely in order to fix bugs without publishing any new binary files to the stores.
Since we write JavaScript code in React Native, we can also use test frameworks in order to test the code like Jest and Jasmine.
Performance
If we think CPUs, multiple cores, and advanced graphics, mobile devices nowadays are like computers. Mobile applications are super responsive and full of complex animations and gravity effects.
We can’t afford our next mobile application to have less than that, and under deliver. We can’t compromise on a low or non-responsive application.
React Native includes many challenges in the performance perspective, for instance:
- When the user presses a simple button, many messages are sent back and forth between the Native side and the JavaScript side. This might lead to frames dropping and laggy behavior.
- React Native ListViews experiencing hard to perform when dealing with long lists.
- Interactive animations are hard to achieve.
These are only a few of the many challenges we need to deal with when it comes to performance in React Native.
Most of our efforts will go to these kinds of tasks, and performance issues might lead to mediocre user experience.
In some cases, might even lead to writing platform-specific code, like complex grid views with complex animation, or animation while scrolling.
Scaling
React Native opens the door to JavaScript developers to write mobile applications. JavaScript is a dynamic-type language. JavaScript only interprets on runtime and doesn’t compile.
Tools like TypeScript and Flow try to soften the problem and offer great typing like tools which are supported by the vast majority of the IDEs (VSCode, WebStorm, Atom).
In order to have 10x more developers, you need to have strong testing methodologies, unit tests, E2E test, and integration tests. Without that, it will be hard to scale and will be hard to release the next application version.
Scaling also means that your app will do more. JavaScript is a single-threaded language, and when you do more, it means that the JavaScript thread will be busier by UI tasks, network requests, heavy computing and processing messages from the Native site to JavaScript side and vice versa.
When the JavaScript thread is busy, things start to have a delay and wait on the JavaScript events bus, meaning the application starts to lag.
At this point, you must examine the project architecture that was chosen. When the application loading time is greater than 10 seconds you have to deal with timeouts in the code and eager approach, instead of lazy loading approach.
But there is nothing special to React Native technology here, only the fact that you are getting punished earlier when you make wrong decisions because of the single-threaded limitation.
React Native is a new framework (~4 years) and the APIs still aren’t stable and break from version to version. Upgrading to the latest React Native version is hard and painful.
Conclusion
React Native is awesome! Though it comes with a price.
You won’t pay this price if you bootstrap your application, have a POC or want an application that doesn’t do much. But if you want more than that, you’ll deal with performance and scale challenges.
React Native is getting better, its super strong community and big companies like Facebook, Wix, and Pinterest choose this framework and are constantly improving it. Making the React Native choice is a smart choice, yet a risky and challenging one nonetheless.
It’s all about setting expectations.
For a simple application, containing just lists and simple pages with images and some text -React Native is perfect. But, if your application is a more complex, like a game with graphics and other visual effects, than React Native might not be the right fit.
