Should you choose React Native for your mobile project? (part 1)

James Hartt is an Equal Experts Associate based in Brighton, UK. Over the next few posts he’ll be sharing his recent experiences with using React Native.

Let’s imagine you’ve been busy developing Native apps all this time, and you’ve just come across Facebook’s ambitious, cross-platform React Native project. You’ve absorbed all the buzz, dreamt of the  development savings, and you’re now wondering: is it suitable for your project?

10 Weeks with React Native

I was recently lucky enough to spend 10 weeks working with a good friend of mine (Alex Jarvis, an excellent Lead Mobile Engineer) at a major tech startup, developing for both web and mobile. They were using React Native (let’s call it RN to save my keyboard), and I worked with the team there up to and beyond launch.

I really enjoyed my time working on the project and got to soak up the best and worst aspects of RN. I think it was the right decision for them to use RN – but is it for you?

Well, over the course of three posts, I’ll be sharing my thoughts on React Native – the good, the not so good, and yes – whether you should use it.

I’ll try to not get too bogged down in the technical details here – but feel free to give me a shout (@thesecond_t) if you have any specific questions.

Let’s get stuck into the positives first.

1. Redux (a ‘predictable state container’).

There is a reason I’ve put this at the top. It’s simply the best way I’ve seen, in over six years of making apps, of changing the lay of the land (mutate state) inside an app. You don’t have to use Redux in your RN app, but I think you’d be mad not to.

These pure function reducers allow you to take the whole state and return (or reduce) to the next state of the world – without returning a modified (non-mutated/pure) version of the original state. They’re a joy to write, in my experience – much better than most imperative pyramids of doom.

Thanks to the discipline of Redux, I was able to implement a feature in just three lines of code, which in native would easily have required some sort of imperative hack. Composition is the order of the day in RN; it’s refreshing and frankly makes you code better. It’s also the main reason we achieved insanely high stability in the app we released (an almost unbelievable v1 crash rate of only 0.1% on iOS, with Android not far behind).

2) Quick development cycle

Creating and honing views for your app is so quick with RN. While in native you can get an idea of what something looks like (using ‘Storyboards’ in iOS, for example), in RN you can knock something up in code just as quickly as a WYSIWYG editor. Live/Hot reload is magical and you must see it in action!

3) Performance

Right out of the gate, you’ll be seeing 60fps on the slowest of devices, even on scrolling content (and with little performance tweaking required). This is because of the interesting interplay between the Javascript and the native layer. This kind of performance is often hard won with Native, but basically handed to you in RN – it’s fabulous. On the flipside, though, if you do run into a performance issue, it may be more of a headache to solve.

4) Creating ‘Native Modules’

These provide functionality for each of the separate platforms; I found it fairly easy to edit existing OS modules to adjust as required and add new functionality. Creating your own is a fairly well travelled path, too.

5) Rich, active community

For a bleeding/cutting edge framework, there seem to be a lot of people using RN (outside of Facebook, too). It seems like a lot of high profile outfits (such as Artsy) are moving over to it in a big way.

6) Facebook uses it

You definitely benefit from the fact that Facebook actually uses RN in a lot of its major, enormously successful products. The same can’t be said for cross platform frameworks like Phone Gap/Appcelerator/Xamarin; while these are all established and well used products, they don’t benefit from the level of exposure, nor the same incentives, that Facebook’s use provides.

7) Javascript + Safety

If you’re coming from a statically typed language (Swift, C#, Java), Facebook’s Flow and a liberal use of eslint rules can help you end up with something approaching a type system. Just about enough to keep you on the straight and narrow in comparison to other Javascript based cross development platforms

8) Dropping down to Native

If you don’t feel like creating a module and need to perform some sort of native hack to get something done, it’s easy enough to do and well documented.

9) JSX makes styling a dream

I have a specific, personal vendetta against WYSIWYG view creators (e.g. Interface Builder), so perhaps I’m biased here. But I found constructing views in JSX  – which is basically XML, and looks like it – to be very refreshing. It drives home the main reason why Facebook has taken on RN for development at scale. Applying Styles is incredibly easy, and a lot of CSS-like properties are shared. I found it much more usable than dealing with all the weird and wonderful properties of UIKit, for example.

10) Bundled ‘Components’

With almost everything in React (Native, too) being a Component, you’d expect there to be a homogenous collection of components that work well on all platforms, right? You’d expect correctly – and they are all extremely easy to take on board and become productive with.

So, there’s a lot to love when it comes to React Native. Sadly, nothing’s perfect – so in the next post, I’ll look at the downsides.

Read part 2 or part 3.