A Practical Guide to Choosing Your Next React Framework
We've started (and finished 😊) a lot of projects here at Planes, and being a team that loves to try new tools, we've gained a lot of experience in what works and what doesn't for React projects. It can often feel daunting making the choice since the most popular frameworks dictate very different approaches to setting up your projects. Hopefully, this post clears up a few of the key decision points when setting up your project.
In this post, I'll run through the reasons for using a framework and it's caveats, specifically, the following:
Not an exhaustive list, however, these are currently a few of the most popular ways of starting and building a React app, each with their own distinctive use-cases.
High-level: A tool to help you set-up a single-page React application
Description: Create React App is ofter the first tool you'll use when getting started with React, mostly due to its simplicity (and it's ties with React itself). However that's not to say it can't be used for a production web app, CRA comes with a number of advanced features out-the-box including TypeScript, advanced caching using service workers, Progressive Web App support and code-splitting. If your project grows out of CRA and, for example, you need to add some custom functionality to the build process you can always override the defaults using (react-app-rewired)[https://github.com/timarney/react-app-rewired] or even eject from it completely.
- SEO, although search engines do mostly crawl JS these days it's probably not the best fit if this is important to your project.
- An internal admin dashboard
- Why? Because you want to be able to work quickly, you aren't fussed about SEO and, being a single-page-application, it will feel snappy.
- A responsive, offline-first web app
- Why? Because CRA comes out of the box with a service-worker for offline support and code-splitting for better performance on mobile.
High-level: A React static-site generator
Description: With a clear use-case, Gatsby is the go-to for React blog developers, in fact, this site was built with Gatsby. Building your Gatsby project will result in each of your React pages outputting a single HTML page. As you can imagine this is a very preferment way of serving up a React app as all the work done by React is at build time rather than in the browser or on a server. You can also leverage off a large library of Gatsby Plugins, examples include tools to optimise images at build time and tools for generating sitemaps.
- If you have lots of Dynamic Content or require users to authenticate then Gatsby might not be for you. Although it is all possible, you'll likely run into more headaches than its worth.
- A Contentful Blog
- Why? Gatsby can be generated based on a data source such as Contentful, meaning your blog writers can write from the comfort of a Headless CMS and you can build the site in React.
- An SEO optimised marketing website
- Why? Because gatsby sites can be very quick to load, and there are lots of handy tools for optimizing images and outputting SEO boilerplate such as sitemaps and metadata.
High-level: A framework for building Server Side Rendered (or SSR) React apps
Description: Next.js solves what was previously a very difficult problem - server-side rendered React. SSR involves building a static version of a page/component on a server, delivering it to the DOM where it then behaves like normal client based React. There are SEO benefits to being pre-rendered (a search engine could crawl the page without JS enabled), and performance benefits as your code can be split by page and cached in its rendered state on the server.
Caveats - As your app grows in complexity you will likely come across ergonomic issues, changes to how you might have previously implemented authentication for example, and other issues that you might not come across with a simple client rendered React app. It's easy to look at the Next.js website and think that it is as easy as writing React.
- A Medium style site where logged-in users publish public crawlable content
- Why? Next.js is server-rendered, so all content will be SEO ready whilst also providing you the framework for implementing logic such as authenticating other parts of your app.
- A Blog or Marketing site
- Why? Although Gatsby is in some ways more suited to this use case, Next.js does have all the characteristics of an excellent framework for this use case. In fact, working with Next.js when you don't need it's more advanced features reduce it down to a very simple and enjoyable development experience.
Although you are never fully locked in, it's worth looking at your projects likely long term requirements and choosing based on those. At Planes we find ourselves using Next.js for the majority of Web Applications and Gatsby for static sites, but love it when we get the opportunity to use CRA, just for its simplicity.