Image without description
  • Jacco Meijer
  • |
  • May 12, 2022

Comparing React app, Nextjs and Gatsby

A new React project starts with a React toolchain. Main tools in the chains are SSR, React server components and GraphQL.

Create-react-app

The most simple React app is a <script> tag on a HTML page. Add JSX and CSS prefixing, and you have the typical minimal setup.

This is what create-react-app is, a very practical minimal setup.

facebook/create-react-app

Create React App is a comfortable environment for learning React, and is the best way to start building a new single-page application in React.

Server side rendering

One of the first requirements from the minimal setup is Server Side Rendering (SSR). The two most popular toolchains that provide SSR are Gatsby and Next.js.

Gatsby

Gatsby is a static site generator that added new features with each major update. With the first major release in 2017, Gatsby integrated Relay with the GraphQL Cursor Connections Specification.

The third release promised future support for React concurrent mode and React server components.

Next.js

Next.js started as a Node.js backend toolchain. With the third major release in 2017, Next.js gained support for static export.

Next.js added alpha support for React server components in version 12.

Comparing the three

Main tools in the chains are SSR, React server components and GraphQL. Other notable differences are in hosting, development cycle, ecosystem and how opinionated the toolchains are.

Hosting

This is where Next.js differs from create-react-app and Gatsby.

Next.js runs on a Node.js backend. Pages requested by a browser are dynamically generated on the backend. Besides generating frontend pages Next.js has the tools for easily setting up a backend API.

Create-react-app and Gatsby are hosted on a Content Delivery Network (CDN). This is easy to scale, secure and low cost.

Dynamic behavior of apps that are hosted on a CDN require a separate active backend such as a GraphQL server.

Development cycle

The latest release of Next's is version 12 while Gatsby's latest release is version 4. Both started development around 2016.

With 12 versions in 6 years Next.js has a rapid development cycle. With 4 versions in the same period, Gatsby's development cycle is very stable.

The development cycle of create-react-app is simple, it follows the version of React itself.

Ecosystem

The ecosystem of create-react-app is excellent. Anything React can be used.

Both Next.js and Gatsby have a large ecosystem with plugins, examples and discussions.

The major difference comes from the development cycle. The rapid cycle of Next.js causes a lot of the ecosystem to be outdated. Due to the stable cycle of Gatsby, versions in the ecosystem are a lot clearer.

Opinionated

Create-react-app leaves everything open. You decide. Styling, routing, SSR, etc. Gatsby is more opinionated. It does SSR for you, suggests how to do routing and leaves styling to be decided.

Most opinionated is Next.js. SSR, routing and styling are all taken care of. Choose the one that fits and go with the opinions given.

SSR

A major requirement for many projects. Both Gatsby and Next.js offer this out of the box. Adding SSR to an app created with create-react-app is not a trivial task.

React server components

React server components are easy to setup with create-react-app because the toolchain does not have an opinion on SSR.

Next.js has alpha support for Server components since version 12.

How to implement Server components in Gatsby remains a question since Gatsby does not have a backend component. As Server components become stable, support might be added in an upcoming Gatsby release.

GraphQL

Create-react-app and Next.js don't have an opinion on GraphQL or which GraphQL client to use.

Gatsby however, has the Relay client preconfigured for build time data. A common Gatsby setup is to use the other major GraphQL client, Apollo, for runtime data.

With Next.js, both Apollo and Relay can be configured. In that case, the major differences with Gatsby are the normalized Gatsby GraphQL schema and the Gatsby source plugins.

Normalized Gatsby GraphQL schema

Gatsby stores all data fetched by source plugins to render pages. This data is tied to React components by using the 'graphql' template literal.

Internally Gatsby uses the Relay compiler. The internal Gatsby schema therefore follows the GraphQL Cursor Connections Specification.

When data from an external GraphQL server is used to render pages with Gatsby, two schema's are in play.

  • The schema of the external GraphQL source. Data retrieved is normalized and stored by Gatsby.
  • The internal Gatsby schema. This schema is used to tie data to React components.

Other posts

Image without description
  • Jacco Meijer
  • |
  • Mar 21, 2024

UI Library with MDX documentation

Using the simple Render JSX plugin for Esbuild this post shows how to setup a simple UI library.

Image without description
  • Jacco Meijer
  • |
  • Mar 20, 2024

Render JSX plugin for Esbuild

Transform Esbuild generated JSX bundles to HTML pages.

Image without description
  • Jacco Meijer
  • |
  • Mar 19, 2024

Esbuild as a static site generator for MDX

Static site generators gain popularity. This blog is about using Esbuild as a static site generator for MDX.

Image without description
  • Jacco Meijer
  • |
  • Mar 18, 2024

11ty and Github pages

Simplifying the Contentful-Gatsby-Netlfy trio.

Image without description
  • Jacco Meijer
  • |
  • Mar 15, 2024

OWASP and CISSP

OWASP recommendations from the independent information security certification CISSP.

Image without description
  • Jacco Meijer
  • |
  • Jun 30, 2022

NPM7 and @npmcli/arborist

@npmcli/arborist is a powerful library that handles the new NPM 7 workspaces. This blog is about a simple make tool that uses the library.

Image without description
  • Jacco Meijer
  • |
  • May 12, 2022

Comparing React app, Nextjs and Gatsby

A new React project starts with a React toolchain. Main tools in the chains are SSR, React server components and GraphQL.

Image without description
  • Jacco Meijer
  • |
  • May 10, 2022

Versioning strategy for NPM modules

It is important to be able to bump the version of a NPM package without side effects.

Image without description
  • Jacco Meijer
  • |
  • Apr 12, 2022

React component themes and CSS variables

Creating React components with flexible themes by using CSS variables.

Image without description
  • Jacco Meijer
  • |
  • Mar 21, 2022

Content modeling with variants

The efficiency of a variant field in a content model.

Image without description
  • Jacco Meijer
  • |
  • Mar 12, 2022

Documentation

Documenting a software project is challenging. Here's a few simple guidelines that help a team writing clear documentation.

Image without description
  • Jacco Meijer
  • |
  • Mar 11, 2022

Javascript history

In 1986 David Ungar and Randall B. Smith developed Self at Xerox PARC. Inspired by Java, Scheme and Self Brendan Eich created Javascript in 1995.

Image without description
  • Jacco Meijer
  • |
  • Mar 10, 2022

On Javascript transpilers, bundlers and modules

There's Javascript transpilers, modules, bundles and bundlers. This is a brief overview of all of these.

Image without description
  • Jacco Meijer
  • |
  • Feb 11, 2022

Agile Scrum

The Agile Scrum framework is flexible enough to be used in many different ways. Here's one way of working.

Image without description
  • Jacco Meijer
  • |
  • Jan 20, 2022

What happened to Wheelroom?

Founded in 2018. Started to fly in 2020 and abandoned in 2021. What happened?

Image without description
  • Jacco Meijer
  • |
  • Jan 19, 2022

Contentful, Netlify and Gatsby four years later

What did we learn from using Contentful for four years?

Image without description
  • Jacco Meijer
  • |
  • Jan 18, 2022

Typescript interface for React UI components

How to define an interface for React UI components that prevents breaking changes.

Image without description
  • Jacco Meijer
  • |
  • Jan 17, 2022

Naming React components

What's in a name? A clear naming strategy helps developers communicate. Most devs rather spend time writing component code than wasting time on a good component name.