React: Fundamental Answers
Facebook’s developer platform questions the dogmas of application development.
React, Relay, Flux, GraphQL, and React Native are ruthlessly pragmatic developer tools.
Fundamental questions begin each week on Software Engineering Daily.
Fundamental answers conclude each week with a coherence of lessons from the podcast interviews.
React interviews on Software Engineering Daily:
- React Router with Michael Jackson
- React at Facebook with Ben Alpert
- Redux with Dan Abramov
- GraphQL and Relay with Nick Schrock
- Fluxxor and Flux Architecture with Brandon Tilley
- React Native with Tadeu Zagallo
- ReactJS with Sebastian Markbage and Christopher Chedeau
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.
Declarative code makes it easier to reason about application behavior. “React wraps the DOM’s mutative, imperative API with a declarative one, which raises the level of abstraction and simplifies the programming model.” React components describe the state of the UI at all times.
What are the synergies between Flux, React, GraphQL, and Relay?
Facebook’s libraries are loosely coupled. It isn’t mandatory to use any specific combination.
- React uses view components with a unidirectional data flow. Single-direction data flow simplifies DOM rendering.
- Flux is a pattern for reasoning about applications with one-way data flow. It solves some problems of model-view-controller, such as cascading updates.
- 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.
- GraphQL is a data query language for describing complex, nested data dependencies. Relay uses GraphQL as its query language.
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?
“Learn once, write anywhere” is the mantra of React Native.
After building a web app in React.js, a developer who wants to port to native iOS or Android needs to rewrite some code.
Facebook lost developer velocity when engineers started building the mobile versions of the Facebook website.
This punishes a design-heavy app like Facebook, where developers want to tweak one pixel and see the result immediately.
Facebook engineers write about porting one app from web to React Native:
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?
Prediction: Facebook will build a React operating system.
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“.
We need to break the mobile duopoly:
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.
Sounds like a great opportunity for Facebook.