The React project at Facebook gained a lot of popularity in the past year, with its to main Github repositories earning a combined 60,000 stars. And while React was initially open-sourced in 2013, it was not until last year, along with the announcement of React Native, that the project's popularity took off.
With its take on declarative user interface building and the excitement of better mobile development experience using React Native, project has lit a fire in the JavaScript community and influenced coding practices by directly challenging established coding practices and conventions. At the center of the project has been Christopher Chedeau, a front-end engineer at Facebook. The Practical Developer had some burning questions about the future of React.
How has React Native affected ReactJS and vice versa?
Rendering Targets
One thing many people are confused with is that React Native is not a reimplementation of React for Native. React Native actually uses the same exact React code under the scenes. React Native provides a different set of primitive components. Instead of having <div> and <span> as low level primitives, it has <View> and <Text> which are baked by their respective counter parts in iOS and Android.
React Native is not our first attempt to target something other than the DOM with React. We had a charting library called ReactART targeting canvas, svg or vml based on the browser capabilities. While it was certainly possible to do so, it would require some hacking. Once we were able to prove that React Native could work, we initiated a proper separation between React internals and the renderer. We now have React, React-dom and React Native.
What's really exciting is that this helped external people write other renderers for React. There are active projects targeting 3D and virtual reality, terminal and even hardware such as LEDs.
Performance
One of the biggest concerns we had when we started the project was around performance: could React and JavaScript compete with native in terms of performance? What we found is that it is indeed possible to write apps using React Native with great performance.
The big takeaway is that the difference between mobile and web is around performance characteristics. On web, you want to minimize the total time it takes to render and update things, which is where React does a great job. On mobile, you need to respond within a fixed amount of time.
Everyone is talking about 60fps for a reason. You typically have a 16ms per frame limit to respond to a user touch interaction or animation. If you don't meet this deadline, the user will likely notice.
We've been approaching this problem on many fronts. First, architecturally, we are using a pipeline architecture where the ui thread talks to the js thread, which then talks to the layout thread, which next talks to the "React Native core" thread, which finally sends operations to the main thread and repeats. This approach enables us to use the multiple cores that phones have.
JavaScript is still single-threaded, so we are looking at ways to better schedule operations. We use InteractionManager to avoid doing computationally expensive work while an interaction or animation is running, requestIdleCallback to schedule work at the end of the frame before the next one kicks in, and an animation API that's both expressive and can be ran outside of the js thread -- splitting up the React rendering work over multiple frames.
The other big area we invested in is tooling. Unfortunately, there is not a silver bullet that's going to make your app run faster, most of the time the best way to make an app run fast is to profile it, find the bottleneck, aggressively optimize it and repeat. Once you've done that, you need to have a continuous performance testing to find and fight regressions that are going to creep in. In order for those to happen, you also need to change the engineering culture to care about those. None of this is React Native specific. We are using these learnings for the web side of things as well.
The sprawl of platforms and conventions causes a lot of development pain that React’s abstractions remedy. How do you expect this to unfold over the foreseeable future?
Problem
When I started working on React Native, I thought that there were fundamental differences between iOS, Android, and the web. However, the more I re-implemented things for React Native, the more I realized that if the naming and languages are ignored, they still perform the same functions in very similar ways, but are incompatible between each other.
You can see this if you are looking at popular apps: developers want to do the same things for the three platforms baring small design differences. It’s unfortunate that in order for developers to build on mobile across three platforms, you need three different engineers because there are three different sets of tool chains, languages, and API’s.
The React Native take
I recognized the aforementioned problem over two years ago but didn’t feel confident that it would be fixed anytime soon. I considered React Native an ambitious project that was designed to solve a problem that shouldn’t have existed in the first place. There have been countless projects that attempt to resolve the cross-platform issues but none of them bring any fundamental value to the table. So, you might get your hands on a new platform, but quickly learn that it’s very similar to what you previously used, does not support multiple platforms, and introduces a variety of issues trying to interop with both existing platforms.
React Native was originally referred to as “React iOS” for most of its existence, but wasn’t platform-agnostic. I wanted the project to succeed because it is better and not because management forced developers to use it due to the cross-platform feature. This was a very difficult challenge as UIKit and Xcode set the bar really high.
The first big differentiator is React, which is a fundamentally different way to build UIs. Interestingly, we are now building our native iOS app using the ideas we used with React and the obj-c framework called ComponentKit.
The second is the emphasis on the developer experience itself. We provide a much better developer experience by shortening the edit-reload cycle using the interpreted JavaScript programming language and a newly built packager tool built for speed. We also provide much needed tools such as red and yellow box to present errors in a better way, an element inspector to quickly find the piece of code that generates the UI sections, Chrome console, debugger, and network panel.
The thrill of the project is that the benefits of React Native extend beyond what I previously highlighted, as the open source community embraces it into their own environments. Our open source approach is important because we’re helping each other be better and most importantly create new standards in today’s complex technology environments.
Our goal is to provide a strong set of API's for other companies to embed as a React Native view inside of an existing application. If you end up realizing that you want to go back to native, you can gradually step out by writing your new views in pure native.
With that said, there are a number of companies with different strategies and challenges to face. While the future of what exactly this will look like is unclear, I’m hopeful that focusing on the developer experience while maintaining an open and transparent environment will continue to be a priority.
React has illuminated a debate about “separation of concerns” and it seems like you personally lit a lot of the fire around “CSS in your JavaScript”. How has the community reacted, and how have these reactions evolved the way the core team thinks about these things?
I think that "separation of concerns" is mostly a way to explain and rationalize the template/JavaScript/CSS architecture. If you write your code that way, then it makes sense to talk about "separation of concerns". But this is not the only way to build applications. If you look at the iOS environment, it doesn’t have style sheets or templates, and yet write applications just fine.
The reason why React and React Native do it differently is best explained by looking at the history. Facebook front-end has historically been written in PHP -- where you would build your HTML with echo and string concatenation. However, there are security concerns associated with this approach because if for some reason you forget to escape user provided data, you can inject arbitrary code that will be executed.
A clever engineer solved this issue by promoting HTML as part of the PHP syntax. Writing echo <div>{$text}</div> is valid and automatically escapes the $text value. Not only did it solve the security issues related to string concatenation but it also opened up the ability to build custom components, enabling you to build the entire website mixing HTML and code. We then ported the idea to JavaScript and it worked equally well there.
For styles in JavaScript, I neglected to implement a CSS parser and rule evaluation engine (I already rebuilt the layout part of CSS). I was convinced that I would need to do it at some point but delayed it as much as I could.
It turns out that this was a good decision. Not only did we not need CSS, but it also solved a ton of issues that we had with CSS at Facebook. I presented at NationJS as an attempt to address the controversy associated with JavaScript styles and to help provide some educational background before announcing React Native a few months later.
Once we did announce it, I had absolutely no idea that React Native would trigger such a wide movement of people trying to find different ways to define styles. Our inspiration came from the post-launch discussions and internal prototype developments on the web side of things — the React Native approach is a bit too radical in the web environment.
How does React fit into Facebook’s greater development philosophy?
We are part of an organization at Facebook called product infrastructure. Our mission is to create ways to move faster, iterate with confidence, and build more reliable software. With that said, every bit of software we use today is made with other software that has already been built. We build software tools to build software and more importantly, we incorporate open source software into our existing software. So, the way in which we build software today has been developed over decades leading up to today.
React has influenced a number of other frameworks, including and excluding the UI, and has pushed us toward a more functional, declarative, and asynchronous solution – away from imperative paradigms.
When we have a potential solution, we leverage real projects that need support and iterate on it with our solution because we know that to deliver software with the speed and quality we want, we will have to rethink everything about how we build.
More of the developing world gains internet access. What is the dialog like at Facebook regarding how these projects can serve the needs of an evolving world while also providing stability to the developers adopting and working on the technology?
Facebook has a very interesting characteristic in that the product is universal. Outside of translation, people all over the world have access to the same product.
The challenges of making the world more open and connected that our engineers are helping to solve create the same experiences that I was able to access as a Frenchman in Paris.
The biggest difference isn't around how people want to use Facebook but the technology they are using to access it. The computing power of the phones and network connections are more challenging in emerging countries. This is actually a positive situation to be in as an engineer at Facebook because making the app work well under challenging conditions requires creative thinking. If you can make Facebook work better on bad network conditions, it usually will also work better on stronger network conditions; improving many global user experiences at once.
Are there any Facebook projects outside of the React universe that people should be talking about more?
Related to the front-end world, the two I have in mind are Rebound and Pop which aim to write animations related to gestures more easily. I was greatly inspired by them when writing the Animated API on React Native.
If you are into static analysis, Hack, Flow and Infer are projects to keep tabs on. The traditional way for people to work on those was to create a new language from scratch with those properties. Being able to augment an existing and popular language with a type system and use it at scale is a very exciting prospect. 😀
OSQuery is a very unusual project coming from our security team. It enables you use SQL to query running processes, open network connections, etc. This is a big improvement over having to parse the text output of various Linux commands and is a good example of improving the developer experience.
I am continuously inspired by the ongoing and unique ways we’re able to improve tooling via open source projects and I really hope to see more collaboration in the community continue.
Top comments (0)