This is a simple guide for humans to not get lost into the React bootstrapping solutions out there.
Starting a React project implies the configuration of multiple tools like Webpack, Babel and more to create the foundations of your web application: depending on the project requirements the configuration can get complicated and hard to maintain. This is the reason multiple code boilerplates started to popup on code platforms like Github: the evolution of few of those boilerplates eventually led to the creation of more advanced and specialized tools such as CRA, Gatsby and Next.js for most common needs.
Actual footage of a developer configuring webpack and Babel for a React project from scratch
The first step to make a choice is to understand what problems the tool solves, and if these solutions match our needs.
Let’s start from the end.
When to consider CRA for your project
- The application is single page and self contained on the frontend (no need for server).
- The application relies on server APIs
- You want to experiment or get started with React
- You want to try a new React project and pick utility libraries on your own
When to consider Gatsby for your project
- You are building a landing page
- You are building a static website (and the team likes React?)
- There are particular pages of your website in React that needs to be super performant (move them to Gatsby if they are already in CRA for instance)
- You need better Search Engine Optimization (SEO) or AMP (Accelerated Mobile Pages)
When to consider Next.js for your project
- The application is composed by both a server and client side
- The application is already in express.js and it needs to be extended also on the client side
- You are building a dynamic website
- You need SEO or AMP and you have dynamic content
Want to know more? Grab a coffee and continue reading…
A Single Page Application is a web application made of a single HTML page but “virtually” by many other pages created dynamically on the frontend side.
CRA creates a simple web application to start, with most of the required configuration for most Single Page Application needs, for any taste: Typescript, CSS preprocessors like SASS or LESS and more. The application is bound to a single HTML page that, when open, loads the React application providing an incredible Developer Experience (DX) for the development process: errors won’t stop development any more, installing new dependencies doesn’t need to stop and restart, and more!
Note that there’s no bundled react library with CRA, or i18n, state management or other advanced features, so it’s completely up to the developer to pick the right library to include in its project. This makes the bootstrapped project less opinionated and ready to experiment with any React library or quickly prototype a basic application.
The final product of a CRA build is one single HTML page, with JS and CSS files containing the web application bundle. This means that the build folder can be statically deployed anywhere and it does not depend on any particular web server.
What if the configuration provided in CRA is not enough yet? There are few projects out there that help on that, like react-app-rewired project, which can be used in (likely) rare scenarios.
Would it be possible to have the development experience of this tool on the server side? Use React to build a website that loads like static but it’s fast as a SPA when using it? This is the idea that powers Gatsby.
The product of a React SSR is a plain HTML page, like any other backend rendering technology: the advantage of using React can be the “hydrating” process that can make it become a SPA on the front-end as explained below.
The goal of Gatsby is to make the development of websites super performant, leveraging the React developer experience. Although the website is modelled as a SPA – even with a routing system in React, the Gatsby router – what it actually happens is that Gatsby will build both a static website and also a SPA out of it. The React SSR version of Gatsby can be seen as a “compile” step for all pages to let you serve them as static content.
Like CRA, Gatsby has many configurations providing support for Typescript, CSS preprocessors and more. Gatsby is particularly focused on websites, and it provides out of the box a system based on GraphQL for easy content fetching, with a multitude of plugins for theming and any kind of support.
The reason to build both a static version of the website and a SPA is to provide an instant loading of the website in few milliseconds via the static version, then “hydrates” the website with an equivalent React SPA to make it interactive: this means that the user will see the website have an excellent performance on first load, then on click it behaves as a client application without reaching the servers again.
This sounds awesome right? In fact this is great, but it comes with a limit: the website must be static so all possible HTML pages must be created in advance. This means that dynamic routes are not possible in websites built with Gatsby.
About the deployable artifact, with Gatsby we’re still building frontend assets: a folder full of HTML pages and JS/CSS scripts. But is it possible to have a real server developed with React SSR with the possibility of a SPA on the front?
The answer to this is Next.js.
Next.js works as a web server or it can be integrated into bigger node (express.js, hapi, fastify, etc…) applications, providing React as rendering engine: there are some additional React conventions in this tool to keep in mind, because the same application page can be rendered on the server, on the client or in AMP (Accelerated Mobile Pages).
Next.js provides a full React SSR experience with dynamic page rendering.
What if I need something different?
Using one of these tools will be probably the best bet to start with, but the React community managed to get some magic out of the hat already few times in the past, so feel free to explore out there for new and wonderful discoveries.