Why React-Native: Part Nine
The last piece of our React Native Series covers what to consider when choosing react native.
2nd Jul 2018
Why React-Native: Part Nine
What to Consider When Choosing React Native
This series wouldn’t be complete without taking a look at where React Native may not be the right choice. So, when shouldn’t you use React Native? Almost never. I actually consider it irresponsible of a development team to start with anything else at this point. I realize that sounds like a crazy fanatic statement, so let’s add a little context to understand why it’s not that crazy or fanatical.
One code base is easier to debug. If you’re writing an app for iOS and Android and you’ve used native specific projects in the past, you know that you’re not just writing, testing, and releasing one app with one team, you’re doubling everything. And, if all of the development work is doubled, so is the management, process and cost. React Native doesn’t 100% “just work” on both platforms, but the differences you’ll run into are far easier to find and fix than running two projects.
Sliding scale. With no intention of burying the lead, this particular point is what won me over. Just because you are using React Native doesn’t mean you have to have your apps written in only React Native. It’s entirely possible to mix between JavaSript and native code in any amount you wish. If it makes sense to write 80% of your app in native code maintaining both code bases, you may still want to code the other 20% using React Native. Maybe you have a processer intense app that you need all the native performance you can get, but you’re still likely to have login and registration forms, settings screens, contact and support interfaces, etc. – all of which are easy to write and support using React Native while the native side handles the heaviest processing load. Typically, you should try to start with only React Native and fall back to native when its necessary.
So, when wouldn’t you want to use React Native? Maybe you’re writing an iOS only app. Maybe you’re so heavily invested in your native code base that changing it would put your product at risk. Or, maybe your client’s CTO just really hates Facebook and gives you no choice. But, whatever the reason you choose to not use React Native, it’s still worth knowing what it can do for you on your next project.
Before I sign off, I want to share a few more tidbits.
- Microsoft is currently working on React Native for Windows, so your React Native apps can run there as well.
- React Native Web is a project that takes your React Native app and allows you to run it in a browser with the same code bases using webpack.
- There is a project for React Native on Apple TV as well as Samsung’s TV OS Tizen.
And one final note: there are competitors to React Native. Google’s Flutter.io is promising with Google behind it and great documentation. However, it uses Dart as its base language, which does not have a great deal of a community behind it. Vue is a framework that competes with React and there is a project to use NativeScript to build a Vue Native framework. The concept behind both of these are the same as React Native. This is a good sign that React Native is a strong enough technology where it’s changing how we think about developing native apps and encouraging others to think differently as well.
So, what are you writing your next app with?