
We don't know how much longer we can have to wait for React Native, but the React Team is slowly giving some hints on its [Twitter](https://twitter.com/reactjs) account.

What we know is that React Native might be

> [@danmatthews](https://twitter.com/danmatthews) imminent
>
> — React (@reactjs) [March 6, 2015](https://twitter.com/reactjs/status/573872611853123584)

And that, it's going to be for

> [@corbtt](https://twitter.com/corbtt) just iOS. Android as soon as we've shipped an app.
>
> — React (@reactjs) [March 10, 2015](https://twitter.com/reactjs/status/575318723399172096)

We don't know anything else yet, but at the end of this month, on March 25th, a couple of months away from the [React.js Conf  
](http://conf.reactjs.com/), the [F8 2015](https://www.fbf8.com/) Developer Conference it's going to take place.

It might be a nice chance to finally release React Native to the public.


React Native is going to be for iOS


While we wait and hopefully approach the official release of React Native from Facebook we can catch a glimpse of the founding technologies that will power our future apps from the guys who are lucky enough (attendees of the React.js Conf) to test it.

Among them is Robbie McCorkell that posted a really interesting article: [React Native – The Killer Feature that Nobody Talks About](http://red-badger.com/blog/2015/03/04/react-native-the-killer-feature-that-nobody-talks-about/).

From his article we're borrowing the following snippet (actually, a fully working sample app).

[TappyButtonApp.js](https://gist.github.com/robbiemccorkell/464482c178c3784df9c1#file-tappybuttonapp-js)

```javascript
/**
 * @providesModule TappyButtonApp
 * @flow
 */
"use strict";

var React = require("react-native/addons");
var { Bundler, StyleSheet, View, Text, TouchableHighlight } = React;

var TappyButtonApp = React.createClass({
  getInitialState() {
    return {
      score: 0,
    };
  },
  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.label}>{"Score: " + this.state.score}</Text>
        <TouchableHighlight
          activeOpacity={0.6}
          underlayColor={"white"}
          onPress={() => this.setState({ score: ++this.state.score })}
        >
          <Text style={styles.button}>Tap</Text>
        </TouchableHighlight>
      </View>
    );
  },
});

var styles = StyleSheet.create({
  container: {
    backgroundColor: "white",
    flex: 1,
    flexDirection: "column",
    justifyContent: "center",
    alignItems: "center",
  },
  button: {
    color: "blue",
  },
  label: {
    marginBottom: 30,
  },
});

Bundler.registerComponent("TappyButtonApp", () => TappyButtonApp);

module.exports = TappyButtonApp;
```

When run it will output a button that, when clicked, will increase the counter.

![Tappy Button](http://i.imgur.com/i3fdAWK.png)


A sample React Native app

React with Christopher Chedeau and Jordan Walke


Two weeks have gone by since the [React.js Conf](http://conf.reactjs.com/) and the announcement of React Native that left all of us lined up, eagerly waiting to build our next apps with JavaScript.

What we saw demoed at the Conference was a demo of what engineers at Facebook proved to be possible with the kind of abstraction offered with the View Layer offered by React.

Even if what we saw was **very** convincing must be remembered that the project wasn't really ready for prime time, meaning it wasn't really ready to be Open Sourced yet.  
Android version of React Native has been spoilered but never shown. iOS version was really a barebone, preassembled project, that the lucky guys attending the event were left tinkering with.

In the meantime we can imagine (hope) that Facebook is unloading more resources to the project to speed it up and keep it with the momentum and the hype created with the announcement.

So what to expect in the coming days (or weeks)?

Some sort of generator is needed to spawn new projects, both iOS and Android, but we cannot possibly know until it's released.  
APIs are going to change both on the markup (JSX) side than on the native bridge side. But, again, we cannot know this until everything is official.

So were are we left us?

React Native is born to address three big pillars: Touch Handling, Native Components, Style & Layout.

React Native is React in the end, and even if it isn't the only choice, what is really going to feed React Views is

### Native Components: [JSX](http://facebook.github.io/jsx/)

We've seen this at work with the MoviesApp Demo both in

```javascript
//[...]
var MoviesApp = React.createClass({
  render: function() {
    return (
      <NavigatorIOS
        style={styles.container}
        initialRoute={{title: 'Movies', component: <SearchScreen >}}
        routeMapper={MoviesRouteMapper}
      />
    );
  }
});`

`var styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'white',
  }
});

module.exports = MoviesApp;
```

and

```javascript
//[...]
var getImageSource = require("./getImageSource");

var MovieCell = React.createClass({
  render: function () {
    return (
      <View>
        <TouchableHighlight onPress={this.props.onselect}>
          <View style={styles.row}>
            <Image
              source={getImageSource(this.props.movie, "det")}
              style={styles.cellImage}
            />
            <View style={styles.textContainer}>
              <Text style={styles.movieTitle} numberOfLines={2}>
                {this.props.movie.title}
              </Text>
              <Text style={styles.movieYear} numberOfLines={1}>
                {this.props.movie.year}
              </Text>
            </View>
          </View>
        </TouchableHighlight>
        <View style={styles.cellBorder} />
      </View>
    );
  },
});
```

and around the internet with some custom Demo Apps

```javascript
"use strict";

var React = require("react-native");
var {
  Bundler,
  StyleSheet,
  Text,
  TouchableHighlight,
  View,
  ScrollView,
  TextInput,
} = React;

var ChecklistApp = React.createClass({
  getInitialState() {
    return {
      items: [{ body: "sour cream" }],
    };
  },

  renderItems() {
    return this.state.items.map((item) => {
      return <Text style={styles.item}>{item.body}</Text>;
    });
  },

  handleSubmit(event) {
    var item = { body: event.nativeEvent.text };
    var items = this.state.items;
    items.unshift(item);
    this.setState({ items });
  },

  render() {
    return (
      <View style={{ marginTop: 20 }}>
        <Text>Checklist</Text>
        <TextInput
          style={styles.input}
          autoFocus={true}
          onSubmitEditing={this.handleSubmit}
        />
        <View style={styles.list}>{this.renderItems()}</View>
      </View>
    );
  },
});

var styles = {
  input: {
    height: 26,
    borderWidth: 0.5,
    borderColor: "#0f0f0f",
    padding: 4,
    fontSize: 13,
  },

  list: {
    top: 0,
    bottom: 100,
    backgroundColor: "#eeeeee",
  },

  item: {
    padding: 10,
  },
};

Bundler.registerComponent("ChecklistApp", () => ChecklistApp);

module.exports = ChecklistApp;
```

So, if you want to invest some time and get ahead of the official React Native announcement, go spend some time tinkering with JSX. Every View is going to be written with the official JSX Syntax.

- [React Fundamentals: JSX Deep Dive](https://egghead.io/lessons/jsx-deep-dive)
- [ReactJS For Stupid People](http://blog.andrewray.me/reactjs-for-stupid-people/)

### Style & Layout: [Flexbox](https://github.com/facebook/css-layout)

Even if, being Open Source, there could be other implementations, it doesn't seem possible that the actual JavaScript implementation of the CSS Flexbox is ever going to go away. So, again, if something, bid on it and learn Flexbox.  
It will look something like:

```javascript
var styles = {
  movieTitle: {
    flex: 1,
    fontSize: 16,
    fontWeight: "bold",
    marginBottom: 2,
  },
  movieYear: {
    color: "#999999",
    fontSize: 12,
  },
};
```

If you want to know and learn more:

- [Flexbox adventures](http://chriswrightdesign.com/experiments/flexbox-adventures/)
- [Flexbox Cheatsheet](http://jonibologna.com/flexbox-cheatsheet/)
- [CSS Flexbox Please!](http://demo.agektmr.com/flexbox/)
- [Flexbox Playground](http://flexiejs.com/playground/)

At least take a look at the minimum specification implemented by React Native.

Name

Value

width, height

positive number

left, right, top, bottom

number

margin, marginLeft, marginRight, marginTop, marginBottom

number

padding, paddingLeft, paddingRight, paddingTop, paddingBottom

positive number

borderWidth, borderLeftWidth, borderRightWidth, borderTopWidth, borderBottomWidth

positive number

flexDirection

'column', 'row'

justifyContent

'flex-start', 'center', 'flex-end', 'space-between', 'space-around'

alignItems, alignSelf

'flex-start', 'center', 'flex-end', 'stretch'

flex

positive number

position

'relative', 'absolute'

### [Flux](http://facebook.github.io/flux/docs/overview.html)

If you're already experienced with these concept then consider investigating on the Flux Architecture.  
React is a View Layer and you're left to figure out how to assemble the rest of your code.  
Well, Facebook did the homework for us, but turns out different people (and companies) figured out a Flux implementation that best suited their needs.

On the topic

- [What the Flux? (On Flux, DDD, and CQRS)](http://jaysoo.ca/2015/02/06/what-the-flux/)
- [Flux For Stupid People](http://blog.andrewray.me/flux-for-stupid-people/)
- [Flux solutions compared by example](http://pixelhunter.me/post/110248593059/flux-solutions-compared-by-example)


What to expect from React Native


Transcript from  
**React.js Conf 2015 Keynote 2 - A Deep Dive into React Native**

by **Christopher Chedeau**.

I'm going to talk you about React Native.  
So the reason why we built it is that we wanted to get the best part out native and we wanted to get the best out of web. When we did the transition from web to native we won at a lot of things.  
The User Experience was better, the performance was better. But we also lost things at the same time, the developer experience was worst, we had to use imperative mutative APIs again, like the DOM, the compile time and linking time, the build time, all of those added up there were advantages we really wanted not to lose from the web.

So in this talk I'm going to tell you what makes an app feel native and I'm going to tell you how we did it in React Native.  
So there are really three big pillars in React Native: the first one is

### Touch Handling

This is, I think, the biggest thing that is different from mobile web. iOS and Android touch handling is much better.  
The second one is

### Native Components

It turns out that there's a lot of really high-quality native component that already exist, and people just try and try to reimplement them but they never feel as good as native. So we really want to be able to use those instead of trying to reinvent the wheel.  
The third one

### Style & Layout

And the reason why it is so important is because layout impacts so much the way you write code and its vastly different from the web to iOS to Android. So we want React Native to be  
Learn once - Write anywhere  
And so we also want to learn one for the Style and Layout.

Let's get started with Native Components.  
The interesting thing about this Movie app demo is that everything that you see on screen is native but when you look at how it's implemented this is the main file

```javascript
//[...]
var MoviesApp = React.createClass({
  render: function() {
    return (
      <NavigatorIOS
        style={styles.container}
        initialRoute={{title: 'Movies', component: <SearchScreen >}}
        routeMapper={MoviesRouteMapper}
      />
    );
  }
});`

`var styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'white',
  }
});

module.exports = MoviesApp;
```

and as you can see this is JavaScript, this is a React component (MoviesApp), there is no Objective-C here, but this component is actually a native one ().  
So let's dig a bit inside of the file and as you can see

```javascript
//[...]
var getImageSource = require("./getImageSource");

var MovieCell = React.createClass({
  render: function () {
    return (
      <View>
        <TouchableHighlight onPress={this.props.onselect}>
          <View style={styles.row}>
            <Image
              source={getImageSource(this.props.movie, "det")}
              style={styles.cellImage}
            />
            <View style={styles.textContainer}>
              <Text style={styles.movieTitle} numberOfLines={2}>
                {this.props.movie.title}
              </Text>
              <Text style={styles.movieYear} numberOfLines={1}>
                {this.props.movie.year}
              </Text>
            </View>
          </View>
        </TouchableHighlight>
        <View style={styles.cellBorder} />
      </View>
    );
  },
});
```

If you ever wrote any React code, this should feel super familiar, but there are still some differences, for example: you've probably never used this component nor this but if I tell you that they are the equivalent of a `<span>` and a `<div>` then you should be ready in a few seconds.  
So how is this View component implemented?  
Well let's open up Xcode and look at RKView.h which is a native one and as you cans ee it extends from UIView.

```
#import "RKView.h"
#import <UiKit/UIKit.h>
#import <FBReactKit/UIView+FBReactKit.h>
#import "UIView+FBReactKit.h"

@interface RKView : UIView
```

So this is actually a real native component that we are istantiating. Now if you look at RKUIViewManager.m and, how is it working? The way we do it is this (View) is a declarative API using React and then we're taking this (RKUIViewManager) and we're going to look at all that attribute that we can have and we're going to extract them and we're going to set them to iOS View mutative one, so this is the same way we implement `<div>` and `<span>` in React, but instead of having to output DOM commands we just output iOS native commands. What's interesting is this ViewOperation, this is done on the main thread so this is the only thing about React Native that's the main thread this is just setting the views so React, all the layout, everything, is done in a different thread and at the end of the diff algorithm all the React logic it's now flushed to the main thread.  
So now you may wonder, how is it running?  
Are we using JavaScript and transpiling into Objective-C or C? No we're not doing it.  
So what we are doing is actually running a real JavaScript engine. In this case what we're doing is we're running a JS call which is the in the JS engine in iOS.  
But let's try something: so we're going to reload Chrome in debug.  
This is all time you have to wait for every single change using a normal native app.  
So what is happening here: we are running the JavaScript, the React app for this, we are running it inside of Chrome, so Chrome is actually running the JavaScript so we're using v8 and all other things, and as you can see you can have all the React Tools.  
What we're doing is: we have a WebSocket connection between the iOS simulator and Chrome, but this is like inside it to get better developer tools we could imagine, and it's already working, getting your iPhone connected via WiFi to your laptop and running the JavaScript that powers the app remotely.  
And once that we can get this why not run it on the server for low end devices? Those are some crazy ideas that are actually possible, we don't know if it they are useful or not, but at least, we don't like to say no to people, and this allows us to say yes if this use case comes.  
And one thing that would be cool is: what if we could server side render native apps? Maybe?  
We could do it!

So this is just a simple app. Have you looked at the time it takes to reload?  
Imagine the Facebook that takes multiple dozens of seconds in order to do any small change, we really want to fix this. So this is how we are using native components and then the next thing is you may wonder: okay we can render native components but how do you style them?  
If you're coming from the web you're going to say use CSS. But unfortunately CSS are some issues, and we've been using CSS at Facebook for a long time and we've had to do a lot of workarounds around it, and it turns out that we believe that there's a better solution and it is writing CSS in JavaScript.  
I did this talk two months ago at NationJS and this was the reaction on Twitter. But, we're not stopping to get used to it, this was the exact same reaction that we got when we opensourced React.  
People complained that now you're colocating your mark up with your logic in JS. For the same reason that it turned out to be a good idea we believe that colocation your style with your JS is a good idea.  
So those are all the issues with CSS. Qt first I was like: writing style in JS isn't going too well, using it, it turned out all those were solved without hacks.

So how is it working? This is how you declare your styles.

```javascript
var styles = {
  movieTitle: {
    flex: 1,
    fontSize: 16,
    fontWeight: "bold",
    marginBottom: 2,
  },
  movieYear: {
    color: "#999999",
    fontSize: 12,
  },
};
```

If you ever written any JavaScript this should look super familiar, you shouldn't be lost from CSS, but there are a couple of differences, you have to put commas instead of semicolons, nothing really big, but what most people stressed on this is: how do you use the styles? And this is it.  
You're using inline styles.  
So, it's been 10 years, and all the best practices stated well: do not use inline styles. So what changed?  
Well I would phrase it otherwise. What's the difference?  
This is how you write styles right now on React and so if you look at the two they are pretty similar, the first thing you'll notice is that we're not using classnames anymore, no big debate about this anymore, we can just use 'style', and the next thing which is a lot more fundamental is look at movieYear: this is a string, and why would we want to do a string, the string it has to be a reference to something in the CSS, and it's global, this is there because we were separating technologies: JavaScript and CSS.  
What we should do is to separate concerns and so we still have this separation of concerns with this because the actual styles are separated from this call but we can use all the power of JavaScript, this is just a JS Object, you can use all the functions to generate those, you can use variables, we just got them in CSS, you can exports, you have a module that shares all your variables and everything, we believe that this is a much better thing.

But this is only one part of CSS that we ditched, CSS is actually much more than that, I would say it's not modular for all that means, CSS also has a big property which is layout.  
If you take this screenshot and you put yourself in the GPU's shoes everything is just boxes full of pixels, the goal of the Layout it's to build those boxes, its only goal is to compute four values: Top, Left, Width and Height, and that's it.  
It turns out there's a lot of ways to do it.  
We first looked at how iOS does it because we wanted to be native and the first thing is you can implement a method called sizeThatFits. What it requires you to do is to write code that computes those four attributes (Top, Left, Width, Height) for every single element that you see on the screen. iOS developers have to write pages and pages of just boilerplate code just to display simple things.  
The next thing that iOS has is Auto Layout. Auto Layout is using a constraint solver, and they sold it in a shiny box, but if you think about it, since Auto Layout is a constraint solver so you've got to define linear equations and you still have two sets: Top, Left, Width and Height in equations on all of the elements that are on the screen. So if you're building applications using it then you don't get that much of boilerplate but unfortunately linear constraint solvers cannot express everything that you want, for example it cannot express line breaks, so you can not have multi-line encoded in a linear constraint solver. There are ways to work around this but all of these ways, they loose the mathematical properties that is going to give you the absolute best layout, which is why use the constraint solver first place.  
We didn't find anything that we really liked in iOS so we turned back to the web. So the first thing on the web is the CSS box model, and this is the best way to do layout I found.  
Just with these 3 simple attributes: Margin, Padding, Border you can express the layout for every single element you want, very easily. But if you want to layout multiple elements: this is insanity.  
For instance try to vertically center something with CSS in multiple columns, with floats and tables...  
But it turns out there's a better way: which is

### Flexbox

If you've never used Flexbox you should try it.  
Let's take an example. We've got this and as you can see there are two columns, and the text is vertically centered.  
I would challenge you tonight to try to implement this using CSS, and let me know it goes.  
But with Flexbox is actually super simple just do alignItems center to vertically center them and flexDirection row to layout things in in multiple columns.  
I'm a big fan of Flexbox but if you think about it React Native is a JavaScript engine for the native components and nowhere in there is Flexbox.  
Because when you are on the web, Flexbox is implemented inside the browser, we don't have a browser, we don't have a WebView, so how do we implement this?  
Well, we are all developers: we fire Jasmine and we start writing some tests. What the layout engine does is: it takes a tree of styles and it outputs a tree with the same shape but where all the values are just four numbers: Width: Height, Top and Left.  
I started writing some test like this to implement Margin, Padding, all the Flexbox attributes but at some point I didn't know if what I was implementing was correct. So since we're in the browser, in this particular example, we can just take this tree as input and create actually real DOM elements and put some styles and we can send them to the browser and ask the browser to computes for us the Top Left Width and Height.  
So I did this for a while but at some point I couldn't find examples where my algorithm was failing, so I thought I'd generate a bunch of tests.  
The right thing with this is I can just generate a lot of frontend test, send them to my implementation then through the browser and see if it passes or fails.  
So the workflow was the following: I would run the tests, find the first that failed, I would fix, iterate, find the first one that failed, fix it, iterate, and at some point there would be no failing tests, and so at this point I was confident that the implementation was right for all the attributes that it supported, and then I added new attribute and I did it again.  
This way I was able to reimplement Flexbox, with all the attributes that we wanted, in about 2 weeks, which is crazy.

I want to put emphasis on the fact that we only really implemented a subset of CSS and the reason why is CSS has a lot of things in it and a lot of legacy things that we may or may not want to support, and so we focused on only the things that we know are useful for the developers and only the things we know we can implement fast.  
So at this point we had Flebox implemented that was working right in the browser. But this is React Native, we want to use it in iOS, so how do you do that?  
The first idea that comes to mind is: we're going to take Flexbox, take the JavaScript implementation and bridge it and execute like real time JavaScript but for doing layout you need to measure text and all the text measurements APIs are in Objective-C and we've got one very important prerogative for the bridge between JS and Objective-C, which is that: its asynchronous.  
So we ported this implementation between the two, actually we will also port it to Java.  
So now we've got the same layout implementation, running on all the three platforms. Since its probably useful to have any condition without any dependencies is on the browser we also opensourced it a few months ago  
[https://github.com/facebook/css-layout](https://github.com/facebook/css-layout)  
so if you need to use it feel free to grab it.

How is it working in practice?  
This is the MoviesApp and we've got a request from the designer that says 'I don't like the image to be on the left, I wanted to be at the top'. We fire up the editor and we see that it is actually using inline styles, and it is actually written in JavaScript in the same file, and using Flebox, so as a developer we should handle it with ease.  
Instead of rows we want them in columns, after hitting save, it is going to instantly reload because we have file watchers listening. This is the promise of React Native: we want less than one second delay between modifying one line of code and show it to the screen.  
If you compare this with the Xcode rebuilding that I showed you earlier, it was like 30 seconds for this small projects.

And it takes advantage of all the ES6 goodness.  
After implementing the score the app broke, well what just happened? As you know with React we tried to do warning as best as possible and this is what we're doing for React Native.  
If you have an exception we're not going to hide in the console, we're going to show it in your face! Internally we like to call it the Red Screen of Death.  
What we really want with React Native is that if your familiar with JavaScript and React you should be able to get started very easily and should get like the same developer experience of the web.  
What you don't see here is that all the JavaScript that we ran is being using ES6, it's compatible with anon modules so if you want to use underscore, or the Parse's SDK or whatever you just have to do is NPM install and if it doesn't have dependency on the browser it's just going to work.

At the end of today we are going to give access to a private github repo that contains React Native.  
Just a warning: what you're going to get is just the bare minimum to run this them demo app.  
Because actually three weeks ago we didn't know we were going to talk about React Native, we didn't know we were going to open source it so we crunched for the past few weeks to get it really stable, but in the next few weeks we're going to have a lot more things.

Question time.

Q: What do you guys have in mind for getting started  
A: The way you get started is with a simple Xcode project that you copy and paste that is already set up in the repo. About build tools that's something we're working internally.

Q: How do you integrate with platform specific APIs as ApplePay or anything  
A: The way the bridge work is you can just expose a JavaScript function. We showed an example of a Component but you can expose any function that you want.  
The only constraint is that the bridge is asynchronous.

Q: How use this for desktop apps?  
A: Right now we're focused on iOS and Android but we're trying to thing bigger, but it's a matter of resources.  
We're working on the infrastructure so maybe one year under the road... or if you're interested in spinning up the process for Desktop you can. Here the're nothing iOS specific, if you can bridge Components and Native APIs you should be able to do it.


A Deep Dive into React Native


Transcript from  
**React.js Conf 2015 Keynote - Introducing React Native**

by **Tom Occhino**.

When Instagram joined Facebook they had a bunch of projects they wanted to work on, and one of the first ones they wanted to do was Instagram.com.  
So they took a look at Facebook's stack and they thought React was really cool and they wanted to use it.

### Open Sourcing React

The problem was that at the time React was really really tightly coupled to our Facebook specifics Software stack.  
So they wanted to decouple it so they can use it on Instagram and Pete Hunt  
convinced us that this is worthwhile.  
He actually did most the work to effectively make React Open Sourceable. So at JS Conference 2013 we decided to do just that, and first impressions were pretty skeptical.

What they told us was that we'd taken a "huge step backwards" in terms of the maintainability of our code, simply because we were embedding our markup, our HTML, inside our JavaScript.  
But internally it wasn't controversial at all. We had a ton of experience with the syntax because we've been using it for years already, at least four years at the time.  
The most important piece about this was that it allowed us to create composite components.  
These server composite components wouldn't just send down the network the markup, it was sent down with all of the style and presentation information that you needed, as well as all the JavaScript that made the thing actually do something. But we went one step further than that, we actually made it so you can create components that took in very simple parameters like a viewer and what type of data you want and they would you all the necessary data fetching to make it so that you have a fully functional dynamic component with all the data that it needs just by calling that API.

And then behind the scenes, under the hood there was all sorts of parallelizing of data fetching across components and there was cashing layers and CDNs. But as a client of this component I didn't need to think at any of that. I don't need to worry about how it worked, it worked.  
The implementation didn't matter to me, this is a component, this we feel is the proper

### Separation of concerns for applications

Facebook was kind of accused of rethinking established best practices, simply because we were storing our markup in our JavaScript. But we actually appreciated it, like finally someone is acknowledging we're rethinking the way that everybody's doing things so perhaps, not coincidentally Pete gave a talk at JS Con and he called the talk

### Rethinking best practices

This talk went over a lot of React's principles, its fundamental principles that made it exciting, and it went over a lot of the things that made it powerful.

But if I was asked everyone in this room, individually, what it is that makes react powerful I think I'd probably get a bunch of different answers.  
The most common the most obvious one is the Virtual DOM. This is React's claim to fame, this is the thing that kinda set it apart initially and now we have stand-alone Virtual DOM implementations which is awesome.  
But another feature that a lot of people called out as being React's most powerful feature was server rendering.  
But for people who aren't familiar with React they'd probably call out the descriptive warning messages as the most powerful feature. When you use this framework for the first time and you do something wrong it tells you exactly what you did wrong and how to fix it.  
There's also the custom event system and a bunch of other features.  
But the thing that makes all these features and more possible is the fact that react replaces imperative mutated API with the declarative API that favors immutability.

When we create our applications using declarative code and when we structure our views declaratively your code is significantly more predictable. The fact you can open up any JavaScript file with the React component in it and understand all of the possible states have that component and exactly how it's gonna behave just by looking at that file is incredibly powerful. And when code is declarative and therefore predictable we can make changes to it more easily with confidence.  
Engineers don't need to spend it on a time trying to understand the entire system before they can make a change to one small piece of it.  
But the best part I think about being able to make changes the confidence is that when you can change your code more confident the ends up being a lot more reliable.

So I think that React's real power lies in how it makes you structure your code in terms of

### React components

The only reason anything like the Virtual DOM or conceptually rendering  
on every single update is even possible is because we use React components  
rather than trying to force things in the models views and controllers we separate over concerns in the components.  
Components are the fundamental building blocks of our application.

What it is about React components though, that makes them different, cause a lot a framework figured this out, we have directives, web components, a lot of other frameworks got it figured out that components are the right separation of concerns but what makes React different well from my experience the difference is that in all those other situations you have to create your component using comparative mutated code but in React you get to describe your component declaratively and I've proposed that the clear code is a lot easier to maintain an easier to extend. And additionally again from my own experience is just a lot more fun.  
So we think we really had home run with React we're using everywhere internally everybody loves using the stuff, but the problem is were only using it for web stuff.

We've also got these iOS and Android apps with hundreds of millions of users and we've tried in the past to just build web apps that we could wrap in thin native wrappers. But it doesn't work. The reason that you can't just build a web app and expect it to behave like a native app is because building for the native platform yield a vastly different user experience than building for the browser environment.

In native we have the ability to parallelize work under multiple threads.  
We also don't have sophisticated gesture handling, this is another thing that sets native apart on Web.  
Another thing we have in native is access to platform-specific capabilities and components. Native widgets are a black box, we don't have access to the source code, we can't see what the parameters are, we don't know what the numbers are that different things that make them feel like they feel and anytime somebody tries to reimplement a native widget using HTML, CSS and JavaScript it always feels like sh\*t.

So as much as it pains me to say it, known hate to say it,

### The native environment is far more flexible and far more powerful than the browser environment

At least today.  
But all that power and flexibility comes with a cost. The native environment is in general far more hostile to developers and to organizations. When we started building a native specific iOS app and a native specific Android app we had to spin up two separate sets of tooling, two separate sets of instructions and all these specific platform code and infrastructure and teams that it wasn't portable.  
We couldn't reuse these concepts and not only that, now we have to think about things like memory management and thread concurrency and laying out subviews and also we have to think about things like provisioning profiles for our devices, you can't just load up a browser window anymore, you also can't just push your entire application by saying 'git push', now you have to think about the deployment process.  
So it adds an unnecessary overhead in developing applications. And there's another reason it's hard to build native apps. In native, just like with the DOM, you have to use mutative imperative APIs and we've seen this before, whenever we try to build a sophisticated application using those APIs over time as it gets more complicated, and we add more people to the team, this breaks down.

Let's get back to React from the beginning: React has been designed to be able to replace any View system can wrap any imperative View system, it doesn't need to just wrap the DOM. What if we take the exact same React's JavaScript we've been running on Web and we can use it to power truly native applications?  
Well that's exactly what we've been working on.

We're calling it

### React Native

and we're building it simultaneously for iOS an Android.  
Now I'm primarily gonna focus on react iOS today but again we're building it for both platforms.

So the first thing I'm gonna show you here is a very simple Movies app. So this app it literally just lists out movies and you can tap any other movies and see a detailed description of it and you can go back, and this is pretty simple.  
I can search for movies.  
The things you can't see is when I tap the native status bar this thing scrolls to the top, the native behavior, the other thing you might not notice is as I'm swiping, this is the native navigator, this is actually iOS, these are native components.

The next app I'm gonna show is actually in the App Store.  
This is Facebook's Group app. It is actually a combination of native code and React Native code.  
We have this multi photo post, you can swipe between photos, put them away, view previous comments here. I'm gonna focus this text box, what happens this is pretty cool when I go to the top of the post I'm no longer in the feed anymore I'm in a permalink view and I can post.

### So What was that?

The first thing to note and the most important thing to note is that everything you saw on the screen was completely native, we can't use the web to build an experience like that.  
So there was no HTML, there was no browser, there were no web views, but it was completely controlled by JavaScript.  
Now there are other frameworks that exist today that scripts native API's in JavaScript.  
There's a problem though, the problem with wrapping native is you still have to use these imparative mutative APIs. The only thing that they change is the code that were writing in. So if you just introduced JavaScript naively this could actually end up being a lot worse. If we're naive here we can get into a situation where we're dropping frames in the UI because we're waiting on JavaScript to do some work, for example JavaScript could be running garbage collection, and our main thread is dropping frames. So for going to introduce a JavaScript layer we have to be smart about it, the layer needs to be asynchronous, that way we can do anything we want the JavaScript thread and we won't affect the actual rendering UI, we won't block.  
And additionally for perf we should be able to batch up all the instructions we want to execute on native and then execute them whenever we can, so will yield to the main thread whenever we need to.  
We know that React diffs subsequent versions of the Virtual DOM so it's perfect for this, we create these diffs, we create these sets of instructions, we throw into a task queue and we execute them in native.

It turns all those imperative API calls, when we're running this on the web, into DOM, set attribute calls and things like that but again there's no reason we have to render to the DOM, so we had to set a primitives on the web `<div>`s, `<span>`s and `<img>`es.  
But on the native platform we have a different set of primitives UI Views and Text, Images on iOS, on Android the Android's Views. So we take this task queue, we interpret all these things that came in all the changes that need to be made, it used to be set attribute, Id, set color and now we turn them into imperative native calls.  
And this is actually where a lot of the work for React Native when we have these thin wrappers that basically convert those declarative properties into imperative code. But probably the coolest thing about this is that we can take advantage of multi-core architectures a lot better.  
By putting a JavaScript in a background thread we can make it so that all of your application logic including your rendering is always executing off of the main thread.

With this architecture we're saying, all your application's code, all of your JavaScript is running off the main thread by default.  
So just like when we introduced React a couple years ago, this is working for us, it's in the App Store.  
Some people think that since we have this tool at our disposal now we're just going to revert back to having a single code base. I wanna make it very clear that that's not our goal we don't want to have a single code base that powers all our applications, all our platforms, we're not chasing the "Write once - Run anywhere"  
pipe dream. These platforms have different looks and feels, different behaviors, and when you're building an Android application you're not thinking about iOS principles, you think about Android.  
So instead what we wanna do is chase the

### Learn once, Write anywhere

paradigm. We want to be able to develop a consistent set of tools and technologies that let us build applications using the same set of principles across whatever platform we want.  
What this means is that a set of engineers can build an iOS app and they can turn around the next day and build the exact same app for Android just by virtue of knowing React. They don't need special IDEs or special environments they can just build using React.

So we're gonna Open Source this soon.  
It's still pretty bare-bones but we're adding more to it every day so there's going to be features dropping and landing everything single day.
