I am still getting people reading this article nearly two years after writing it - which is awesome! But unfortunately, a lot of what is in this article is out of date.
I wrote a new version of this post updated for 2021. It can be found here --> https://dev.to/jameesy/gatsby-vs-next-js-in-2021-what-why-and-when-2fae
Ok firstly, I digress, I am a massive fan of both of these "frameworks". I can usually be seen gushing about them on my Twitter or Instagram, however, without a doubt, the question I get asked the most when talking about these tools is which is better?
Should I use Next.JS? But I have heard Gatsby is pretty 🔥, maybe I should use that?
So I thought I would discuss it a bit further in-depth and hopefully make the choice a little bit clearer.
LETS FIGHT!
Gatsby & Next - An Introduction
So what are Gatsby and Next other than buzzwords you have heard mentioned before but never really understood?
To put it in the most basic terms, in the same way, create-react-app will create you a boilerplate of a React project, these two frameworks will lay the foundations for you to create an application.
They have separated away from create-react-app however, in the sense that they are not classed as boilerplates, but toolkits, laying the foundations and then giving you a set of instructions on how to build the house as well.
To summarise:
create-react-app - Lays the foundations of a React Project. The rest is up to you.
Gatsby & Next - Lay the foundations of a React Project. Give you guidelines on how you should build on top of them.
...
But huh? That's strange? They both do... the same thing?
Sort of.
At first glance, they both look very similar in the sense they both:
- Provide a boilerplate application.
- Generate incredibly performant, accessible and SEO friendly websites.
- Create Single Page Applications out-of-the-box.
- Have a really awesome developer experience.
But actually, they are fundamentally different.
Server Side Rendered vs Statically Generated
Ok, so we start to get a little bit technical here, so stay with me... It's not too bad!
Gatsby is a static site generator tool. A static site generator generates static HTML on build time. It doesn’t use a server.
Next.JS is mainly a tool for server-side rendered pages. It dynamically generates the HTML every time a new request comes in with the use of a server.
Of course, both can call APIs client side. The fundamental difference is Next requires a server to be able to run. Gatsby can function without any server at all.
Gatsby just generates pure HTML/CSS/JS at build time, whereas Next creates HTML/CSS/JS at run time. So each time a new request comes in, it creates a new HTML page from the server.
I'm not going to go too deep into the pro's and cons of each here, however for some more in-depth reading check out this post - https://dev.to/stereobooster/server-side-rendering-or-ssr-what-is-it-for-and-when-to-use-it-2cpg
Data Handling
Another fundamental difference between the tools is the way in which they handle data.
Gatsby tells you how you should handle data in your app.
Next leaves the decision entirely up to you.
What does that even mean?
Gatsby uses something called GraphQL. GraphQL is a query language and if you’re familiar with SQL, it works in a very similar way. Using a special syntax, you describe the data you want in your component and then that data is given to you.
Gatsby makes that data available in the browser when needed by your components.
An example:
import React from "react"
import { graphql } from "gatsby"
export default ({ data }) => (
<div>
<h1>About {data.site.siteMetadata.title}</h1>
<p>We're a very cool website you should return to often.</p>
</div>
)
export const query = graphql`
query {
site {
siteMetadata {
title
}
}
}
`
In the above example, you can see that we have a query to fetch title and then display title within the component. Awesome!
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 Forestry. This allows you to do things such as hook your site up to a CMS and have external control of the content.
When building for production, GraphQL is no longer used, but the data is persisted into JSON files instead.
... Ok cool.
Next on the other hand, how you manage your data is completely up to you. You have to decide on your own architecture how to manage data.
The benefit of that is that you aren't tied into any tech that you may or may not want to be using.
So what should I choose?
Whether you should use Gatsby or Next depends very much on your use case, as really they are both awesome.
When To Use Next.JS
If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages are not the best 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 fairly slow to rebuild. And if you have to wait for a chunk of time when you hit publish before it goes live it’s not a perfect solution.
So if you have a site with content that you will expect to grow and grow over time, then Next.JS is the best choice for you.
Also, if you want more freedom with how you access your data, Next.JS is worth a shout.
It's worth mentioning here that the documentation for Next is some of the best I have ever come across. It has an interactive introduction that quizzes you as you go through the content to make sure you are following along :) awesome! 👏
When to Use Gatsby
I tend to, and this is my personal preference, use Gatsby when I am building small-scale websites and blogs. The eco-system is perfect for hooking up to a CMS (it is literally a breeze) and there are some awesome guides on how to get going with it all.
It is (in my mind) easier to get up and running with Gatsby, so that is worth keeping in mind. Again, the documentation is to a really high level, packed full of tutorials for you to follow along.
Gatsby also comes with some "starter" templates, as well as a relatively recently introduced "themes" which all make getting a fully functioning web app up and running a quick process.
Latest comments (71)
The link [jame.es/gatsby-vs-next-js-2021] seems to be now moved to:
jame.es/posts/gatsby-vs-next-js-2021
@jameesy
For anyone stumbling upon this on or after 2022-03-02:
The most up-to-date link I could find on his website is:
jame.es/posts/gatsby-vs-next-js-2021
@jameesy The updated link seems broken...Could you plz check it out?
Updated!
I migrated my content to a new site and that particular link broke. Thanks for the heads up!
Still broken, unfortunately. If you have a moment to update it to jame.es/posts/gatsby-vs-next-js-2021, I'm sure it will save cumulative hours of googling for those coming here.
Thanks!
The pleasure is mine :D
Thank you for a succinct, time-saving introduction to gatsby vs next.js difference.
Wonder if you can write about when to use a traditional CMS vs a headless one. All I see is posts touting the benefits of headless CMS. However, I think there must be cases where it makes more sense strategically to use traditional CMS.
Thanks, James. Great post!
That's really the great article on this topic I have come across so far.
Great work man!
Thanks Jamees for this great comparison between NextJS and Gatsby framework, you laid out the core difference when to use these frameworks.
Thanks for this contribution!
Nice and concise. Thanks for the contribution!
Gatsby does not force GraphQL you can do a normal fetch promise to pull in data — it is however preferred and reported to be faster.
Hi Jamees Thanks for a valuable post. I'm curious what CMS platforms you use with Gatsby? My team have experience with a few, all with limitations(features or cost), and there's lots to choose from!
What do you recommend for medium e-commerce (300-500 products) site Gatsby or NextJS in 2020?
excellent, thank you decision made :-) Nextjs it is for me.
Gatsby is rolling out incremental builds now to address the build time at scale.
The 3 paradigms of static sites and why people use react apps.
However all of this problems can be solved using pure HTML/CSS/JS and no frameworks.