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 first time I heard about React I didn't quite get it and ended up dismissing it.
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.
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/>;
}
}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.
<blockquote class="twitter-tweet tw-align-center" data-lang="en"><p lang="en" dir="ltr">A thought exercise: If code-splitting is so great, and bundlers like Webpack make it easy, why don't we code-split every component by default?<br><br>(This is not a trick question)</p>— Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/962772968731328512?ref_src=twsrc%5Etfw">February 11, 2018</a></blockquote>
<blockquote class="twitter-tweet tw-align-center" data-conversation="none" data-lang="en"><p lang="en" dir="ltr">Hint: <a href="https://t.co/zlD8oxgmII">https://t.co/zlD8oxgmII</a></p>— Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/962779670432301056?ref_src=twsrc%5Etfw">February 11, 2018</a></blockquote>
He later gave an example of how native apps solve this:
<blockquote class="twitter-tweet tw-align-center" data-conversation="none" data-lang="en"><p lang="en" dir="ltr">One reason iOS feels so much nicer than the web: fewer unnecessary loading states. Look what happens when you tap an option in the Settings app: rather than transition immediately and show a spinner, it pauses for a moment until the view is ready. <a href="https://t.co/Rt4uWiJW7K">pic.twitter.com/Rt4uWiJW7K</a></p>— Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/954798592320942081?ref_src=twsrc%5Etfw">January 20, 2018</a></blockquote>
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.
<blockquote class="twitter-tweet tw-align-center" data-lang="en"><p lang="en" dir="ltr">Using a new strange API. I never felt this productive using React before. You’re going to hate it, then you’re going to love it. Will spill some beans in a week at <a href="https://twitter.com/jsconfis?ref_src=twsrc%5Etfw">@jsconfis</a></p>— Dan Abramov (@dan_abramov) <a href="https://twitter.com/dan_abramov/status/967242377030262784?ref_src=twsrc%5Etfw">February 24, 2018</a></blockquote>
<blockquote class="twitter-tweet tw-align-center" data-lang="en"><p lang="en" dir="ltr">A certain upcoming feature, in particular, is really hard to explain without seeing a live demo with code. Abstract explanations end up creating more confusion. You need to see the real thing. Stay tuned for <a href="https://twitter.com/dan_abramov?ref_src=twsrc%5Etfw">@dan_abramov</a>'s talk this week at <a href="https://twitter.com/jsconfis?ref_src=twsrc%5Etfw">@jsconfis</a>! <a href="https://t.co/uXsEY3bHWT">https://t.co/uXsEY3bHWT</a></p>— Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/968192494427979776?ref_src=twsrc%5Etfw">February 26, 2018</a></blockquote>
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.
