All these improvements, however, remain in the conceptual stage, with Facebook seeking help from the developer community to implement them.
Speaking at the recent React.js Conf in San Francisco, Facebook Software Engineer Ben Alpert emphasized faster list processing as key to boosting React's performance. "If you actually look at almost any mobile app on your phone, they're all made up of lists," such as a mail client, calendar or phone book, he said. "This is one thing that we think is superimportant to make fast."
There are three techniques for doing this, he said. One is windowing, in which the application only renders what is on the screen. While this sounds obvious, it's not easy to do in React now, Alpert said. "We have some abstractions for this, but they're not as performant as they could be."
A second technique is rendering views in chunks, breaking them up to avoid unresponsive performance. React could render part of a new item onscreen, pause, then let scrolling continue, to maintain responsiveness.
The third technique is doing layout in React itself rather than within the browser. Layout information would be available in the render function for a component, and a default could be in place for widths smaller than a specific size. "This very easily fixes the reflow problem because now you can just render the correct thing the first time. You don't need to render a placeholder and then replace it once you know how big it is," Alpert said. This also makes windowing simpler, he said.
The company also wants to bring its Animated library from React Native, allowing for views to be declarative while state changes continuously, to the React DOM. This would enable the library to be used in Web applications rather than in only iOS and Android applications.
To improve application structuring for code reuse, Facebook's React Native technology, for building native iOS and Android applications via React, could be extended to the Web. Developers could end up with basically the same app for all three platforms, sharing 90 percent of the code. Alpert emphasized this was "just an idea," but it would enable software engineering organizations to have a single team instead of separate Android, iOS, and mobile Web teams.
Facebook wants to make the development process quicker, resulting in higher-quality applications, and simplification plays a key role. Right now, React developers have to configure tools like Babel, Npm, and Node.js, Alpert said. These tools solve problems, but at the expense of simplicity. Developers should be able to create a single file and run it without setting up anything else, Alpert believes.
Data management also is key to the developer experience, so Facebook hopes to combine different technologies now in use with React and offer easy setup and code reuse. Right node, developers use the
setState function to set state of an application, but this keeps state encapsulated and makes it difficult to share with another component, Alpert explained.
Developers also use Flux or Redux for building Web applications and providing a state container, and Relay for getting data from a server into a component. But Relay requires a GraphQL server, which most developers do not have, Alpert said, and it's not helpful if developers have to deal with a lot of client-side data with no counterpart on the server. Facebook envisions combining React
setState, Flux/Redux, and Relay, allowing for easy setup and code reuse.
React has developer tools in place, including third-party offerings like the Deco IDE, but Alpert encouraged developers to build more tools like Deco and Facebook's open source Nuclide IDE.
Alpert said an upgrade, React 15.0, would move to a release candidate stage the week of Feb. 29. It will have full SVG support in the DOM and run 10 percent faster. Facebook also is changing its naming convention for React, reverting from numbers smaller than one to numbers higher than that. "We're really doing this because we look back and say all versions are already production-ready." The current version is the React 0.14 line.