Why is React popular?

Developer productivity is improved.JSX critics usually decide they like the strange markup after trying it out. In my experience, going from TODO MVC to a complex app requires less effort in React than in AngularJS.

Relay is a framework for fetching data in React applications. A developer can specify her query within a component, adjacent to where she uses the result of the query. Different queries within subcomponents can be reduced into a single query, subtracting from the round-trip-time to fetching data from a server.

The central idea behind Relay and GraphQL is that view code is the best place to locate data-fetching code. To do this, each React component will specify its needed data using GraphQL queries; Relay will then fetch the data specified by GraphQL. You might be wondering what the value added of Relay is, and why doesn’t GraphQL hit the server itself for the data, instead of just specifying data needs. The reason is each GraphQL query does not map to Relay doing one server request, as doing this would carry major performance penalties; this would be inefficient because you will often specify the same data dependency in multiple places.

Instead, Relay will take all the different queries sent to it and batch them together. This means if you had multiple React components specifying via GraphQL the same data dependency, they will both get their data from the same server request via Relay. To me, this feels similar to how React components state all of their rendering needs to the virtual DOM, which then diffs itself with the actual DOM before doing any manipulations. Both the virtual DOM and Relay allow React developers to explicitly state the needs of their components, without having to try and be minimal for performance reasons.

How does React Native work?

After building a web app in React.js, a developer who wants to port to native iOS or Android needs to rewrite some code.

React Native applications consist of both JavaScript and native code (either Java or Objective C). The JavaScript runs in a virtual machine on the mobile device and communicates with the native code through a JSON message passing interface.

Facebook lost developer velocity when engineers started building the mobile versions of the Facebook website.

Web developers can live reload their JavaScript by simply saving their files and refreshing the page. iOS and Android engineers have to recompile their entire app to see any changes.

This punishes a design-heavy app like Facebook, where developers want to tweak one pixel and see the result immediately.

The app needed to contain a lot of complex business logic to accurately handle differences in ad formats, time zones, date formats, currencies, currency conventions, and so on. Much of this was already written in JavaScript. The prospect of writing all that code in Objective-C only to later write it in Java for the Android version of the app wasn’t appealing — nor would it be efficient. In React Native it would be easy to implement most of the UI surfaces we wanted to build — displaying lots of data in the form of lists, tables, or graphs. Product engineers could be immediately productive implementing these views, as long as they knew React.

React is the common ground between iOS, Android, and web developers.

iOS and Android engineers will not be replaced by React engineers any time soon, but Facebook is breaking down the silos between mobile engineers and web.

What is Facebook’s business strategy for eating the mobile ecosystem with React?

Facebook wants to “unify the low level implementations and maybe talk directly to the GPU. We can have React that outputs to the virtual DOM and talks directly to the GPU and bypass all of this stack that is preparatory and build a new stack that is designed for React,” said Christopher Chedeau.

Development of native apps is currently bottlenecked by the Play Store and the iOS App Store review processes, which require hours, days, or months of turnaround time from pushing an update to making it available to users.

Facebook wants mobile developers to be able to ship their native apps continuously, just like web developers can.

“We know that the [React] project right now is good, but this is not where we want to go. We are in for the long run. We are deeply committed to it.”

Sebastian Markbage: “We’re trying to see more and more of these output modes. We can talk about web, Android, canvas drawing, iOS. But a lot of companies are doing [other] things. Netflix is targeting TVs using React and they have another view layer. we want to make it easier to get React on other platforms that we are not specifically focusing on. Other companies are using React for games, so running React on gaming consoles is a priority for them. We’re trying to make it more decoupled from the DOM and keep going with this idea of React as a programming model.”

Android devices use Linux with the Java virtual machine. Java provides the thin runtime for communicating with Google’s heavy cloud infrastructure. This is not the only model for “dumb phone and smart cloud“.

The JVM could be replaced with Node.js for an all-JavaScript runtime model.

We already know that there are two dominant mobile operating systems out there. But the current situation doesn’t really allow anyone to experiment, not without going through the interests and lenses of the two dominant players — Apple and Google.

That’s why we need a third mobile OS to break this duopoly and move us towards a more open environment for anyone to innovate, without permission. Especially as mobile phones have begun to democratize and broaden the reach of technology around the world… why shouldn’t we then also democratize the mobile operating system?

Besides resulting in improved discoverability, greater ability to connect with users, and more geographic reach, a more open environment for mobile innovation gives users around the world choice.