This is a simple guide for normal humans to avoid getting lost in the React bootstrapping solutions out there.
Starting a React project implies the configuration of multiple tools such as Webpack, Babel and so on, to create the foundations of your web application: depending on project requirements, the configuration can be complicated and hard to maintain.
This is the reason multiple code boilerplates started to pop up on code platforms like Github: the evolution of some of these boilerplates eventually led to the creation of more advanced and specialized tools such as CRA, Gatsby and Next.js to cater to common needs.
How can I choose the right new project to build?
The first step in making a choice is to understand what problems the tool solves, and if these solutions match your 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 a 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 need to be super performers (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 of both a server and a client side
- The application is already in express.js and needs to be extended on the client side as well
- 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…
Create-react-app (also known as CRA) is an official React CLI announced by the Facebook team behind React itself in 2016: the goal of the project is to provide a simple way to bootstrap your Single Page Application (SPA) in React.
A Single Page Application is a web application created out of a single HTML page that “virtually” involves many other pages created dynamically on the frontend side.
CRA creates a simple web application to start with, including most of the required configuration for general Single Page Application needs, whatever your 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 – this provided an incredible Developer Experience (DX) for the development process: errors don’t stop development any more, installing new dependencies doesn’t mean the need to stop and restart, and on and on!
Note that there’s no bundled React library with CRA, nor i18n, state management or other advanced features, so it’s completely up to the developer to pick the right library to include in their project. This makes the bootstrapped project less opinionated and means it’s ready to be used to experiment with any React library or to 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 does not depend on any particular web server.
What if the configuration provided in CRA is still not enough? In this situation, it is always possible to “eject” from the classic configuration, and customize it. The “eject” task has a major downside, though – losing the ability to upgrade again using the main create-react-app streams.
There are a few projects out there that help with that, like react-app-rewired project, which can be used in these scenarios without a full “eject”, maintaining the ability to upgrade later on.
Would it be possible to have the development experience of this tool on the server side? Could React be used to build a website that loads like static, but is as fast as an SPA when using it? This is the idea that powers Gatsby.
Gatsby is the solution created by Facebook to enable the use of React on the server side, or as it is often referred to, React SSR (React Server Side Rendering).
The product of a React SSR is a plain HTML page, like any other backend rendering technology: the advantage of using React is the “hydrating” process that can make it an SPA on the front-end, as explained below.
The goal of Gatsby is to make the development of websites super performant by leveraging the React developer experience. Although the website is modelled as an SPA – going as far as to have a routing system in React; the Gatsby router – what actually happens is that Gatsby will build both a static website and also an SPA from the material.
The React SSR version of Gatsby can be seen as a “compile” step for all pages, enabling you to serve them as static content.
Like CRA, Gatsby has many configurations that provide support for Typescript, CSS preprocessors and so on. Gatsby is particularly focused on websites, and it provides an out-of-the-box system based on GraphQL for easy content fetching, with a multitude of plugins for theming and every kind of support.
The reason for building both a static version of the website and an SPA is that this provides an instant website load in a 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 has an excellent performance on first load, then with one click it behaves as a client application without accessing the servers again.
This sounds awesome, right? In fact, although it’s great, it comes with a built-in 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.
If we’re talking about the deployable artifact, with Gatsby we’re still building frontend assets: a folder full of HTML pages and JS/CSS scripts. The Gatsby team built a full infrastructure to help optimize the building step for developers, named Gatsby Cloud. The deployment step in Gatsby is straightforward – a simple upload of the folder resources on a web server.
But is it possible to have a real server developed with React SSR that has the possibility of a SPA on the front?
The answer to this is Next.js.
Next.js is a project to bring React to the server side, and combine the SPA experience with it. It’s built with ZEIT (now Vercel), with dynamic routes.
Next.js is open source, developed in Node, and it can be used either as a web server or can be integrated into bigger node (express.js, hapi, fastify, etc…) applications, providing React remains the rendering engine. There are some additional React conventions in this tool to bear in mind, because the same application page can be rendered on the server, on the client or in AMP (Accelerated Mobile Pages).
Under the hood of the build version of a Next application, Webpack is used to optimize the final application artifact (while already optimized, the configuration can be extended at will).
Next.js provides a full React SSR experience with dynamic page rendering. Since Next.js 9.3, a new Static Site Generation feature is available, which aligns Next.js with Gatsby in the static generation market, providing a unique hybrid static and dynamic server rendering tool.
What if I need something different?
The three options discussed here are only the most famous tools in the React world with which to start your project, but there are more available that cater to specific niches or tastes, for instance Docusaurus or react-boilerplate project
Using one of these tools is probably the best bet to start with, but the React community has already managed to pull some magic out of the hat a few times in the past, so feel free to explore what’s out there for new and wonderful discoveries.