React Native is a framework developed by Facebook for building Native mobile apps in JavaScript. It's based on ReactJS, a Facebook library for building user interfaces.

React introduced some amazing concepts to build UI, and these concepts can be applied not only to web browser, but also to mobile. They include better state management techniques, a unidirectional data flow in applications, component-based UI construction, and much more. If you have a React background, you should be familiar with these concepts, but if you don't, no worries. You will see how these concepts are used by following the book.

React Native currently supports iOS and Android and there are plans to expand to other platforms. The change that React Native brings with it is that even while an application is written in JavaScript, it's compiled to Native code, so its performance is much better than so-called hybrid apps. These apps are written in JavaScript, HTML, and CSS and are executed in WebView (a browser embedded inside an app). Besides, React Native brings web-like developer experience, live reloading of your application during development, and much more--things mobile developers only dreams about.

In order to understand the motivation behind creating React Native, it's important to understand what lead to the creation of React Native and what was the motivation for it.

Before looking at the history of React Native, let's take a look at the history of ReactJS. After all, React Native is based on ReactJs and uses its concepts and best practices. For years in web development, there was a mantra: Dom Manipulation is expensive. Basically, it means that presenting your data to the browser or rendering it is a costly operation. Document Object Model (DOM) was built in the 80s to deal with simple HTML documents.

React is focused around the concept of Virtual DOM. Let's understand why this concept is called virtual. DOM stands for Document Object Model and means actual browser API to access HTML nodes structured in a tree-like structure. Virtual DOM is a representation of this same structure, but inside JavaScript without accessing HTML nodes directly.

React has an internal state, and when this state is updated, it knows to update DOM with batched updates. Also, React uses a JSX-XML-like syntax, which lets developers represent their React components hierarchies somewhat similar to writing XML, but doing it inside JavaScript.

Since React uses Virtual DOM, it's decoupled from exact browser implementation. This gave an idea to some developers at Facebook internal Hackathon to write a framework based on a solid React foundation, but that will render a UI not inside a browser, but instead will compile it to Native modules--Objective-C for iOS, and Java for Android.

Yes, you heard it right. Great things emerge when great minds start hacking. That was exactly the case in Facebook internal Hackathon in Summer 2013. After creating React Native, it was publicly reviewed in January 2015 at the ReactJS conference. In March 2015, It was officially released by Facebook to open source and since then it has been available on GitHub:

Almost two years passed, and React Native grew to be the most popular and best framework for developing mobile apps. It even surpassed iOS and Android development according to Google Trends. It's a collective effort of React Native core team and the community, so after finishing the book and becoming a React Native professional, I encourage you to support this collective effort and contribute to React Native development.

Check out the following Google trends comparison between React Native, Android development, and iOS development:

Today, React Native is considered to be the best choice for developing mobile applications since it gives you lots of advantages over traditional mobile development. It's not only a framework for external use. Facebook uses it for its Facebook groups, which is a combination of Native modules and React Native and for Facebook Ads Manager, which is built entirely using React Native.

Apart from being a really cool Hackathon project, React Native had some solid foundation on why it was created in the first place. There were several things in mobile development that became a real bottleneck for companies creating mobile apps. Also, there were some things that the team behind React Native wanted to improve in mobile development workflow in general. Let's briefly look at them.

Let's talk about mobile development in general. iOS and Android are the two most popular platforms. Each platform uses a different programming language, has different APIs to deal with a device, and usually requires a different approach from the developer.

To summarize this, mobile development is coupled to a specific platform. If a company wants to create an Android application, it would need to hire an Android developer. If it needs to develop an iOS application, it will hire an iOS developer. These developers are not interchangeable. Application code, even when doing the same, can't be shared across platforms and basically needs to be written twice--once in Java, and once in Objective-C or Swift.

React introduced new concepts to web development, one of which is unidirectional data flow.

The meaning of unidirectional data flow this means can be expressed in the following formula:

It means that our UI is a function of an application state. That means that, instead of updating the UI directly in an imperative way, we change the state and the UI is updated accordingly by the internal React mechanism.

Let's check the following use case: A user clicks on a button, and it's color is updated. Usually, we attach some kind of event listener to the button click, and when it's performed, we update the button color directly. In React, instead of changing the button color directly, we change the component state and React propagates this change to the UI.

Another concept is splitting your UI to reusable components. Since you focus on each component in separation, it's easier to test and to reuse it across the app, meaning more Don't Repeat Yourself (DRY) code and less bugs.

The declarative nature of ReactJS components and their tree-like structure provide powerful feedback on how your application is laid out. This speeds up development, because code is easier to read and maintain.

The previously mentioned concepts were used for web development, but there were no reason not to reuse them for mobile development. So, these concepts were incorporated in React Native and used upto now. We will cover how this works in detail in later chapters.

One of the important concepts in software development in general is a great developer experience. If your application is not working, you need to debug it. Also, when developing for mobile, each minor change means that you need to wait for your code to compile, restart your app, and watch whether it has changed. React Native was created with an idea of overcoming this short-coming to give the best developer experience, and it succeeded in lots of ways.

Since React Native is based on web development concepts, it allowed developers to use one of the most popular web development tools, Chrome Developer Tools. When you run React Native in the development mode, you can attach your application to Chrome browser and use its developer tools. You can debug your code, check network requests, profile memory usage, and do all the things you can do in Chrome DevTools when developing for the web.

Another new concept that has been introduced into web development and, with React Native was also got into mobile development, is a concept of Hot Module Reloading or HMR. HMR is a technique used by the JavaScript bundling system to "know" which modules were changed and reload them without doing a full page reload.

Introducing this together with live reload to the React Native ecosystem provides instant feedback during development and shortens development cycles.

In terms of layouting your application, layout engines for iOS and Android Native apps are different. React Native unites it under one way to layout your application using a modern web technique called flexbox. Also, you will see when we will get into the code that styles look very similar to inline styles used in web development.

Was React Native the first framework used to build mobile applications in JavaScript? Of course not. For quite a while, there was the Cordova platform. On top of it, there were popular frameworks such as Ionic or Sencha Touch. Cordova created a new kind of application: hybrid apps.

Cordova gave a developer the ability to make calls to Native mobile APIs while writing their application using JavaScript, HTML, and CSS. The reason these types of apps are called hybrid is because they don't really create Native experiences. The resulting app runs inside a WebView as mentioned earlier and may look almost the same as a Native one, but there will always be small things that will matter, for example, scrolling, accessing keyboard, animations, and much more. There were lots of hybrid apps written and published to Play and App Stores, but none of them feel really Native.

So, you may ask, if they are all bad, then why were they created in the first place? There are several reasons:

• Code reuse across multiple platforms
• Development speed
• Web technologies used no platform-specific mobile developers

One of the main drivers of creating hybrid apps was code reuse. Write your code once in JavaScript, HTML, and CSS, and you are good to go. The application will work both on Android and iOS. Of course, it's undoubtedly faster to develop a single application for multiple platforms. For companies, hiring mobile developers for every platform was more costly than retraining web developers to develop for mobile.

When Cordova came out and hybrid apps started to emerge, it all looked very promising, but very fast hybrid apps showed their bad side.

They introduced new architectural complexities and more technologies to use in the project. While the motivation was to let developers create mobile experiences using web technologies, it was not as simple as that and always included involvement in Native technologies; thus, the overall experience was not the same.

Since hybrid applications are running inside a WebView, the level of interaction and performance is very limited. Animations can become laggy and do not compare to the Native approach.

So how is React Native different? Well, it doesn't fall under the hybrid category because the approach is different. While hybrid apps are trying to make platform-specific features reusable between platforms, React Native has platform-independent features, but also has lots of specific platform implementations. Meaning that on iOS and on Android, code will look different, but somewhere between 70-90 percent of code will be reused.

Also, React Native does not depend on HTML or CSS. You write in JavaScript, but this JavaScript is compiled to platform-specific Native code using the React Native bridge. It happens all the time, but it's optimized in a way that the application will run smoothly in 60 fps.

So, to summarize, React Native is not really a Native framework, but it's much closer to Native code than hybrid apps. Now, let's dive a bit deeper and understand how JavaScript gets converted into Native code.