Should you use Next.js or Gatsby?
Note: This article was written in 2019 and is now outdated.
Next.js and Gatsby are 2 of the most popular React web frameworks that have gotten a lot of attention since their inception. At first glance, they both seem very similar.
Both of them:
- Generate very performant websites.
- Generate SPA out of the box.
- Handle SEO very well.
- Have great developer experience.
This makes it difficult to decide which framework to use. However, while they have many similarities, they are fundamentally very different.
What's special about Gatsby?
Gatsby is a modern web framework built on top of React and GraphQL. The main selling point of the framework is that it generates blazing-fast websites that are built statically during build time to make the website faster. It is a toolkit that generates static sites, a.k.a Static Site Generation (SSG).
Although Gatsby is a layer built over React, it has an ecosystem of its own that includes plugins, themes, and starters. This ecosystem is community-driven and extendable by default. It is built as a static site in build time and hosted as simple HTML pages.
What about Next.js?
Next.js is another popular React framework, focused primarily on creating server-side-rendered (SSR) React applications with little to no configuration. Performance historically hasn't been the main draw for Next.js; rather, it has been the improved developer experience and reduced hassle to create full-fledged, SSR-friendly web applications.
2021 Update: Next.js can also act as a Static Site Generator (SSG), support static builds, and Incremental Static Refreshing (ISR), but it still requires a server to handle generation.
Static site generation vs. server side rendering
A static site generator is a script that generates static HTML during build time. It doesn’t require a server to handle incoming requests.
On the other hand, server-side rendering dynamically generates HTML every time a new request comes in. It uses a server for this.
Of course, both can call APIs client side. The difference is that a Next.js SSR app requires a server to be able to run. Gatsby can function without any server at all.
Gatsby just generates pure HTML/CSS/JS. This means you can host it at S3, Netlify or other static hosting services. This makes it extremely scalable to high traffic loads.
Next.js creates HTML on runtime. So each time a new request comes in, it creates a new HTML page from the server.
Data handling
Another big difference between the two React frameworks is how they handle data. Gatsby dictates how you should handle data in your app, whereas Next.js allows you to decide how you should handle your data. Next.js is even capable of hosting its own API through the server for your application.
So how does Gatsby handle data? In Gatsby, all your application data is queried and handled using GraphQL. Let’s say you fetch data from an API. Then you first have to tell Gatsby to import the data into a GraphQL database. Your React components then fetch the data from the GraphQL endpoint during build time.
Gatsby also has lots of plugins for various data sources which (in theory) makes it easy to integrate against many data sources. Some examples of data sources plugins are contentful, Wordpress, MongoDB and GraphQL
When building for production, GraphQL is no longer used, but the data is persisted into JSON files instead.
With Next on the other hand, how you manage your data is up to you. You have to decide on your own architecture how to manage data. You have to make a decision if you want to use GraphQL, Redux, pure React.
So what should I choose?
The answer is that deciding between using a SSR or SSG to develop your web app largely depends on your use case. A general rule of thumb is that if the data initially served on the application is more dynamic and constantly updating, use Next.js. Otherwise, if the initial load does not require data from the server, Gatsby is great. However, there are other considerations as well.
If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages is not a good solution for you. The reason is that it takes much time to build the site if you have lots of content.
When creating a very large app with thousands of pages it can be really slow to rebuild. And if you have to wait 20 minutes when you hit publish before it goes live it’s not a very good solution.
So if you have a site with content that you will expect to grow and grow over time, then Gatsby might not scale for you. And you must not only think about how much content you have now, but how much you expect in the future. How many pages will you have in 1 year? 5 years?
However, if you don't expect the catalog of data to grow too much in the future, and if it doesn't take a long time to build, use Gatsby. By using Gatsby, you'll never have to worry about scaling. You'll be able to handle any amount of traffic because its just static data.
Another reason to use Gatsby is if you are keeping a version history of data and changes. Let me explain.
Let's say you auto build and deploy each time the data changes. Let's say this happens once or twice per day, and you're also storing all older versions on S3.
That means you can always deploy a site with old data. So if new data introduce a new bug, then you can temporarily go back to an old version of the data that works while working on fixing the bug.