Using React to Build User Interfaces

Software development is amazing at putting a lot of power in one place.

With great power comes … a great interface, that allows you to use it properly.

Websites, apps and APIs are all ways to access and control complex software, using something simpler than what is beneath the surface. They are all interfaces.

In business-to-business systems, its users might access that software through websites, apps, and APIs. In business-to-consumer systems, the user accesses it just through websites and apps.

So, this is where tools like React come in — React is one of many tools we use to build out user interfaces for websites and apps.

We’ve framed this discussion around React as a reference point, because if you want to talk about building a front-end in 2020, React is usually going to come up in that conversation. That said, React is often not the most appropriate tool for the job, and we’ll discuss that in more detail later in this article.

What problem does React solve?

React's technical function is to ensure your website or app's internal state matches its user-facing state. That's it.

You can plug in some code to speak to other systems like your CMS or your back-end, you can tell it to relay styling information to the web browser, you can link in fancy 3D panoramas and video etc. but when it comes down to it, React's job is to make sure your solution's internal state is accurately and consistently reflected to the user.

For business stakeholders, this translates to improved digital service reliability. Compared to its predecessors, React makes it harder to introduce bugs into your websites and apps.

So, while React itself only manages shepherding your app's state reliably to your user's screen, the knock-on effects are far-reaching.

The ecosystem around React embodies a culture of "treat the cause, not the symptom." React itself bootstraps developers with the extra time they need to solve other higher-level problems, and as it goes on. Wealth begets wealth.

Your development team, freed from grinding on the same types of bugs over and over again, are empowered to tackle new types of issues. Your designers and product managers will become bolder and less likely to relegate powerful features to the too-hard basket.

When a React user interface is worth the investment

Front-end web development was once notorious for its fickle, "flavour-of-the-month" approach to choosing libraries and frameworks.

The good news is, React has much more staying power than the frameworks and libraries that have come before, due to its focus on sustainable development and internal consistency.

While some technical advantages of React over its competitors are immediately evident, it’s React’s long-term outlook that keeps us coming back to it.

The React design principles are a huge part of that. They are useful and synergistic, some of which I'd like to call out:

• Provide a good developer experience
• Enable predictability at scale through composition
• Enable gradual adoption and provide escape hatches
• Provide stability, by keeping breaking changes to a minimum (never, ever pull an Angular 2)

There is also more empirical evidence that React will be with us for a while:

• React is 7 years old, and developers still don't hate it. That speaks highly of the library, and it makes it much less likely that developers will run into a problem that is so unique that the React community hasn't already solved it.
• Its primary sponsor, Facebook, has bet the house on it.
• This is unlike Google's Angular framework, whereby most of Google's consumer web apps run on something else completely.
• React has already undergone a complete rewrite, without requiring the same from its users.

Of course, no tool is a silver bullet, except for perhaps an actual silver bullet.

When might React not be appropriate?

An interesting aspect of the React community is that it seems to encourage using React for absolutely everything.

That said, there is a growing movement to move in the other direction also, with frameworks like Svelte and Solid boldly stepping into the limelight. (The industry as a whole has learned not to underestimate the viability of the “one-man framework” since Vue became a contender.)

While choosing the trending movement may serve the resumes of developers reasonably well, it is not the right way to decide the technology a project should be based on (although it is a factor in determining how easily you can hire developers for it).

Many circumstances will come into play to determine if React is suitable for your project.

Generally;

• Will your project be more “set-and-forget”, or will it be large enough or around long enough that the investment in reusability makes sense?
• Are you developing an app and need to get to market quickly across as many platforms as possible?

In regard to team dynamics;

• Does your team have an established way of working in React? If not, are they capable of evolving their own way?
• React markets itself as a library and not a framework. Does your team prefer this versatility, or does it prefer a more prescriptive approach like modern versions of Angular provide?

In regard to more detailed technical considerations;

• How will the lack of progressive enhancement out-of-the-box affect your project?
• This will incur a client-side performance penalty unless you use React through a pre-rendering or isomorphic rendering solution such as Gatsby, NextJS or Sitecore JSS.
• React components do not tolerate JavaScript errors. When a component encounters an error, it will abruptly disappear. Developers must provide an explicit “error boundary” to cover for it. Is React’s policy on error handling too strict for your project?

Are you working on tweaking an existing Squarespace or Magento solution?

In all likelihood, React will probably get in the way unless the React part(s) of such a site are sandboxed away from everything else. Solutions built on ready-made site builders and e-commerce platforms remain most maintainable when you don't deviate too far from their preferred ways of working.

Are you developing a largely non-interactive (brochure) website, with a sprinkling of interactivity here-and-there?

Perhaps surprisingly, React can work better than plain HTML/CSS for static sites. For example, building your site in React against the static site generator Gatsby lets you apply many common performance optimisations by installing plugins.

Conclusion

React is all about user interfaces, but not all user interfaces should be React.

Don’t succumb to resume-driven development — pick the right tool for the job, and remember to account for human factors.

React likes to spread its tentacles into all corners of your project if you allow it to, so discipline is needed to limit its usage to where its strengths overlap with your needs.

If your project is large or long-lived, React's encouragement of sustainable development practices will serve you particularly well.

If you want to better understand where your team fits, feel free to get in touch with us.

‍

‍