Why React Native Matters

At this point you have probably heard something about React Native. In fact, chances are someone has extolled its virtues and told you how it signals a new era of writing JavaScript cross-platform apps. This post is here to dispel some of the myths around React Native and share an understanding of what problems it solves.

Even DJ Trump is impressed by React Native's abilities

TL;DR: Skip to the end for a quick summary.

What React Native Isn't

React Native does not solve the same problems as Cordova or Ionic which are used to make "Hybrid Apps". Those frameworks have been created to let you build web applications that can also be deployed in a WebView within a mobile app. However, you are limited to what native apis you can use based on what the mobile WebView can access, for example you would not be able to have your Cordova app poll for network updates in the background.

React-Native also solves a different problem from frameworks like Appcelerator, Xamerin or Codename One, which allow you to write once app that will be transpiled to native apps for both iOS and Android. Note that with these solutions you will pay some costs for the added flexibility.

To understand what React Native is meant to achieve we have to first look at the purpose of the React Framework.

React is Primarily a Design Approach (and then the Framework built around it)

In the beginning of this decade Facebook was facing a problem that many large web apps eventually face: they had a large and complex UI where many views could change the state of the web page. An analogy to this can be seen in a large company; imagine you have a large organization with its documents spread out and duplicated for ease of access in different parts of the company. If someone wants to update a file they will have to make sure that they not only update their copy but also update all other copies throughout the organization. The chance that our hapless employee will complete the update successfully without missing a copy in some small sub-department is minuscule! The more entry points for these updates, the more opportunities will arise for data to get our of sync. So what do you do?

The organization solved this problem by centralizing the "true" sets of documents in one place and providing copies throughout the different departments. They standardize the method by which these documents are updated and ensure that all updates to the documents are immediately reflected everywhere. React's analog to this approach is to have one place for keeping track of state, if a component (view in react) wants to update the state then sets the change in the central state. React then takes care of rebuilding the whole UI with the new state.

If this sets off alarms for you because is sounds expensive, you are right and React has considered that! Going back to our analogy, out hapless employee will be able to update the one true document but they will now have to run the new copies out to the different departments. The organization would fix this issue by providing virtual copies that automatically update so new copies don't need to be created. Similarly the React Framework will build a virtual copy of your UI and take care of only updating the portions on the screen that have changes. For more information about how React counters performance issues check out these resources: [1] [2].

This Brings Us Back to React Native

React Native introduces this same approach to mobile development by having you update your central state when a user interacts with the app (or an asynchronous call completes) and then rebuilding the UI for you as a result of the state change. This can make app development faster as it abstracts away handling state (orientation change, passing data from one screen to another) and makes it easier to manage your UI and state logic by having your components only worry about rendering themselves and triggering a state change rather than changing the UI themselves.

And that is the heart of it, everything else comes as a bonus.

Since Facebook built React-Native with inspiration and tooling from React it made sense for them to have Javascript as the language for writing it. This has three important side-effects. One, it makes mobile development more accessible to web developers. Two, it makes it possible to share many of your react components as well as js libraries across mobile and web platforms. Three, it allows you to think about the design of your app the same way on all platforms.

Give me the Rundown Again?

React-Native does not signal the end of native application development in Android or iOS, nor does it let you develop web apps for mobile. React Native is a framework built around a pattern that makes it easy to keep track of data and state in your application. This framework is constructed so you can build native apps with JavaScript and Java/Obj-C/Swift code.

Wait, where are my pros and cons? I want a list of your ill informed opinions!
Ugh, fine here you go:

Pros

• Use the same libraries across platforms
• High levels of code reuse between platforms
• Lets you think about mobile and Web development the same way
• Helps you centralize state management, reducing the opportunities for bugs
• Eases the pains of native development (state management on orientation change or screen navigation, event listener mania)
• Free

Cons

• You still need to write different apps for different platforms even with high code re-use
• This also makes it easier to customize the appearance of different clients to match the platforms design guidelines.
• Lack of type checking and compile time safety of Java or Obj-C
• Good code styles and a great IDE/Linter will take you a long way in making maintainable and understandable JS code.
• Dependence on third party libraries
• You will still have to do native development on occasion if you want to use an api that is not available to react native already.
• It is still maturing