# React Native: Understanding How It Works in 5 Minutes

Since Facebook's first release of React-Native in 2015, we've seen thousands of articles blossom explaining why we should now use React-Native to develop our native applications.

Yet very often, these articles talk to us about the benefits of React-Native without really explaining how the framework actually works, and its differences with other tools like Apache Cordova, Ionic, or NativeScript.

Having never worked with React-Native before, I was watching the phenomenon from afar; until recently, a client commissioned me for a project with React-Native.

I then started discovering the framework, and based on what I was reading, I thought that React-Native allowed you to compile a React application into pure native code, with no remaining piece of Javascript.

But I was wrong!

Under the hood of React-Native

If React-Native doesn't compile javascript into native mobile languages, then what does it actually do?

Without React-Native

If we take the example of a "hybrid" framework such as Cordova (used by Ionic), the latter generates a native application containing simply a WebView (a native component for displaying a web page inside an application), and your web application's code which will run inside this Webview.

This is more or less what's called an "empty shell".

But then how does it manage to use the device's native APIs? Cordova simply provides a bridge that allows you to write plugins in native language, interfaced with javascript to access these APIs in a simple way.

To sum up: when an application is launched, the Webview is loaded, the bridge is attached to it so it can be called by Javascript, then the web bundle is injected into the webview.

So what we have is not a native application, but a hybrid one (mostly web).

With React-Native

With the framework developed by Facebook, the application's business logic still runs inside a javascript virtual machine, but the graphical components are no longer managed by a webview, but by native code.

Concretely, when you create a element in React-Native, it will be transformed into a UILabel element on iOS and a TextView on Android. Then the component's style (similar to css) will be transformed to match the different layout systems of the different OSes.

React-Native therefore provides a unified API to create and manage the UI of your applications from JSX code.

If we compare it to Cordova, which provided a webview and a bridge for native code, React-Native actually provides a bridge that will manage calls to native APIs AND native graphical elements.

A React-Native application is therefore split into 3 different threads: the UI, the Javascript, and the bridge. This way, the execution of Javascript (asynchronous) is never blocked by the execution of calls to native code (mostly synchronous).

Does React-Native live up to its name? In reality, not really, because it's not a native application that gets deployed at the end of the chain, but a hybrid application (mostly native).

In conclusion

I'll go into detail about using the framework in a future article, but I wanted to write this article to explain the actual (but simplified) workings of React-Native, in order to avoid any confusion, like the one I myself experienced.

And to dispel the myth that React-Native lets you reuse more of your web code than other frameworks, when the very way the framework works is contradictory to that claim.

If you want more details about the technical advantages and disadvantages of React-Native in the real world, I'll leave you with an article published on Uber's blog, explaining why after two years of use the company is parting ways with React-Native.

If you're looking for an alternative to React-Native, you can also try NativeScript, which follows the same philosophy as RN but with a different technical implementation!