Introducing React Native
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.
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.
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
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.
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
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.
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.
Well that's exactly what we've been working on.
We're calling it
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.
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
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.
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.