You hear a lot of buzz about React Native these days, yet most people seem to talk about its ability to run on multiple platforms as its main benefit. However, I think this ignores so many advantages it has over the other options.
I believe that the tools I use to build apps help me be productive and successful in doing so. As a frontend dev, beyond the abilities of the platform, how I write, test, reorganize and refactor my code are critical aspects that make me more effective in my job. It allows me to create more features, prevent bugs, and deliver our product, along with new features, faster to the market.
Native development isn’t getting any easier
The ecosystem for React is rapidly changing, and only the best libraries and best concepts survive. They’re in competition with so many others and have far more options, as opposed to the tools you build your native app with. If you wrote a React app three months ago as opposed to nine months ago, your code would look quite different.
Honestly, when developing an Activity with Fragments I feel like I’m working on Windows Forms again
For example, your new Android app’s code would look very similar to the one you built two years ago. Sure, the OS provides new features. Sure, there some new libraries that help you. But can you really compare the Activity/Fragment concept to React? Including State Management?
The fundamentals of the working methods (which I can’t say I like to begin with) remain the same, and the platform isn’t flexible enough to allow developers to abstract a lot of this mess. Honestly, when developing an Activity with Fragments I feel like I’m working on Windows Forms again, changing the state of my controls by writing this.specificControl.value = result; – that’s so 2003.
Here are a couple of examples that highlight the differences between React Native development and native development that are worth considering:
Developer Experience
One of the first things you notice about React Native development is how fast you’re moving with it. The time between saving a code file and seeing the results is faster than anything you get on iOS or Android. For example, Hot Reloading makes it very easy to test things quickly without waiting more than a few seconds to see results.
Javascript Sugar
Want some sugar with that code? Well hop right on the JS bandwagon! Look at all that sweet sugar we get with JS+Babel (which React Native is shipped with).
I want to specifically note Async/Await. This is a game changer for me. I mean, Promises made things nicer, but this is just fantastic. And I had a great experience with this feature in C#. It comes with scope handling and everything! Better than Callback Hell (hi Swift!) or Promise Dungeon (aka CompleteableFuture in Java, the damn name in JS is even nicer).
State Management
One of React’s major advantages is the way it goes about State Management. I find the way components render very predictable and easily testable.
Obviously you can use your favorite Flux implementation, and in that field you have great options; I’m not even mentioning products like Relay, or tricks you can use to hook up Reactive Extensions to your state beautifully.
The counterparts for native platforms are just not as easy, comfortable or clean.
Testable Code
For this one I must note that not only you do write your code once, you also write the test for it once.
On top of that, you get to use things like Snapshot Testing. React allows you to test not only your logical code, but also your UI code.
When you go about testing an Android app, while you have tools to help you with it, the Activity/Fragment model is just not built to be testable. You have some ways to fake Activities and OS APIs, but even then you are in a far from ideal situation. Even in an MVVM/MVC/MVW architecture (which isn’t even a cool buzzword anymore) you could at least test your ViewModel to determine whether the View will bind to the correct data. In Android your Activity/Fragment is both the ViewModel and the View most of the time.
Using JSON
Since JSON is a first-class citizen in Javascript, developing client/server code becomes a lot easier – even without code sharing between client/server (which is awesome).
Just take a look at some Swift code that reads JSON: What would happen you needed to serialize an unknown type object to JSON? These kind of operations are way too complicated and full of boilerplate in Swift. It’s better in Java, but still a lot less comfortable than Javascript.
To Sum Up
I could go on about the advantages (there’s lots more of them) but you get the idea. Should EVERY app be built with React Native? Obviously not.
Not all apps are the same and it really depends what kind OS APIs you’ll need to utilize, and how. You can still use React Native effectively by writing some bridges for what you’re missing, but sometimes it’s too much of that and native will work better in that case.
But for a lot of apps that don’t render a 3D character over someone’s face, edit music or any other idea that isn’t ideal for React Native – it could be better for you. It is for me.
Leave a Reply