The new generation of React-based UI frameworks
There’s a new crop of web UI frameworks in town, in the grand tradition of Bootstrap, a framework developed at Twitter. Five years ago, Bootstrap was not only an easy way to put together a UI that looked reasonably polished, it was also a great illustration of how to structure frontend code: as a well-documented set of modular, reusable components with a shared design language.
Twitter didn’t invent this approach, but they did a great job of it and shared it with everybody. Thanks, Twitter. A little more recently other big companies have published their own pattern libraries — collections of the UI components that make up their websites, along with the HTML and CSS to render them. Most of these are meant more as a window into process (and as a recruiting tool) than as an open standard that other developers can use, but the principles are the same: a reusable library of components with standardized markup.
Having a strong design system and a frontend architecture that’s designed to support it is incredibly powerful.
Today, even more of the frontend stack has evolved toward a modular, component-based architecture. React is a Javascript library for building UI that’s structured around self-contained components, bundling view logic with markup and styling so that components can be reused anywhere in an app. In a React app, you hardly need a pattern library (though they’re still helpful as a visual reference); the code itself is a self-defining pattern library. Here’s the markup for the Feedback component in MailChimp’s library:
<div class="feedback-block warning section" role="status">
<div class="lastUnit size1of1">
<div class="c-media">
<div class="c-mediaImage v-isFreddicon">
<span class="freddicon warn-circle"></span>
</div>
<div class="c-mediaBody--centered">
<h4>Account status
</h4>
<p> You closed your account on Nov 29, 2013 07:00 pm
</p>
</div>
</div>
</div>
</div>
Depending on the component, you may also need to include a JS file to handle any interactivity or other logic the component needs.
In React, the markup and logic for this component would be defined in only one place, so rendering it would look something like this:
<Feedback type="warning" title="Account status">
You closed your account on Nov 29, 2013 07:00 pm
</Feedback>React’s templating system is JSX — this concise version will get translated into the same markup as the top example in the browser. The great thing about this system is that if the keepers of the MailChimp design system wanted to change this component, they’d just change it in one place — the JSX for rendering it would stay the same. In the old world, updating the uses of this component would be a messy and error-prone find-and-replace operation.
Having a strong design system and a frontend architecture built around it is incredibly powerful. Building new interfaces is like putting together Lego blocks. Rapid prototyping and refactoring are a hundred times easier. More importantly, users benefit from a predictable system that works the same everywhere across an app — every time I see a Feedback block in MailChimp it looks and works exactly the same, so my brain spends less effort understanding what’s happening and more on whatever I’m actually trying to accomplish.
The list of React-based UI frameworks is steadily growing. They differ in design philosophy and visual style, but all serve the same basic goal. Some are the product of a big company’s engineering team, like Grommet or Blueprint. Others are independent and/or open-source projects, like Semantic UI React or Ant Design. A few are based on an existing design system, like Material Design, e.g. React Toolbox and Material-UI. There are even a couple ports of good old Bootstrap.
As I experiment with these frameworks in my own projects, I’ll be posting deep dives into the pros and cons of each one. The first (coming next week) is about Grommet, a framework developed at Hewlett Packard Enterprise. Follow me on Medium for more!
