Blog Feb 27, 2018 · 5 min read

We're ready for the next React

I really enjoy developing with React and I use it for all sorts of side-projects and at work too. Not only in our flagship product but for prototyping new ideas.

The past

The first time I heard about React I didn't quite get it and ended up dismissing it.

Screenshot

A declarative paradigm that makes it easier to reason about your application?🤔

A JavaScript library (not a framework!) for building user interfaces… I'm sure it's great but what are you really talking about? An XML-like syntax called JSX? Inline styles? Turns out these people knew what they were doing and React ended up making a big impact and influencing how we do front-end development.

The present

Fast-forward to 2017 and we have React 16, which not only brought new features but also included a complete rewrite of the core architecture, codenamed "Fiber".

Fiber introduced new capabilities to React, such as error boundaries and fragments, but is not being utilized to its full potential in version 16. In the announcement post you can read:

Perhaps the most exciting area we’re working on is async rendering — a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.

We think async rendering is a big deal, and represents the future of React.

While React was maturing, the ecosystem surrounding it was evolving in many ways. One big part of this evolution was webpack, which has been widely adopted by the community.

One of the most compelling features of webpack is code splitting. It basically allows you to split your code into various bundles. You can manually split your code using multiple entry points. And more interestingly, with dynamic imports you can split code via function calls within modules. This can be very powerful and quite trivial to use. Create React App supports this out-of-the-box and projects like react-loadable make it even easier:

import Loadable from 'react-loadable';
import Loading from './my-loading-component';

const LoadableComponent = Loadable({
  loader: () => import('./my-component'),
  loading: Loading,
});

export default class App extends React.Component {
  render() {
    return <LoadableComponent/>;
  }
}

The future

Speed isn't everything and too much asynchronous rendering can actually worsen the user experience. No one likes loading states and rendering pieces of your app asynchronously brings some new challenges.

I maintain JS.coach and React.parts and thanks to it I end up reviewing many packages and reading a lot of tweets from the community. I have been made more aware of this problem thanks to a series of tweets by Andrew Clark, one of the key engineers that worked on Fiber.

He later gave an example of how native apps solve this:

This kind of behavior is not trivial to accomplish today with React. We may need a paradigm shift to actually take our web interfaces to the next level.

But thankfully it seems the React team is already on it.

I'm grateful for all the work these individuals share and I couldn't be more excited about front-end development. I'll definitely be watching the stream March 1st.

Write a comment on GitHub