In recent years React has had two frameworks dominate its user base: Gatsby and Next.js. Until recently, they had some sizable differences that allowed developers to pick one of the two that made sense for their use case. But, with recent updates, such as Gatsby introducing Server-Side Rendering among other features, the two frameworks became much closer.
Both Gatsby and Next.js allow you to create versatile and powerful React websites using features like Sever-Side Rendering and Static Site Generation and more features that React doesn’t natively support. But, even so, the two frameworks still have their differences. And I want to explore some of the larger differences and offer some guidance on which framework you should pick.
If you’re looking for a quick comparison of Gatsby vs. Next.js, then check out the TL;DR in the conclusion!
Now, let’s get to comparing Next.js and Gatsby.
Data fetching is one of the larger differences that you would encounter when working with either framework. Next.js is agnostic about the data fetching method you wish to use. You can define it, implement it, and consume it however you wish, whether that’s via a REST API, a GraphQL API, or something else. Next.js doesn’t mind.
But, with Gatsby, it’s a different story. While Gatsby does support sourcing data without using its GraphQL data layer. Gatsby advises against this and pushes people to use their GraphQL data layer. This means if you want to query data in Gatsby on your pages or during the build phase, you’ll almost certainly be using GraphQL.
You may be wondering why Gatsby has such a strong preference for GraphQL. And, it’s a fair question to have; Gatsby even has a great article explaining their reasoning. But, essentially it comes down to the wide variety of benefits that come from using GraphQL, like automatically optimizing images and allowing you to load data in the same place it’s consumed. To summarize it nicely using Gatsby’s words: “GraphQL will simplify the process of building and optimizing your pages.”
Now, your opinions on this difference between Gatsby and Next depend on your opinion of GraphQL and if you want to use it for your next project or application. If you don’t like GraphQL, then Next.js will likely be a better fit because you can query data without it. But, if you prefer using GraphQL or want a great opportunity to become more familiar with it, then Gatsby would be a great choice for your next project.
Plugins & Ecosystem
Both frameworks have very vibrant and active communities that contribute to the development and advancement of each framework overall. But, there is a key difference in the structure of these frameworks and how the community influences them. Gatsby has a heavy reliance on its community-authored plugins, which anyone can use in their applications for things like sourcing and transforming data or styling a site.
In essence, Gatsby makes it very easy to template out and create a new website. If you wanted to create a blog, for example, using Markdown, you could use the gatsby-source-filesystem plugin to source all your blog posts to GraphQL and then query them on your page. This is true for other things as well, like adding Google Analytics to a website; just use their
gatsby-plugin-google-analytics plugin, give it your tracking ID, and it does the rest for you.
With Next.js, where there isn’t a plugin community like Gatsby’s, the developer has to do all of this work themselves. If you want a blog using Markdown then you need to source and transform the data yourself. So, if you don’t mind doing this type of work or want full control of the data sourcing process, as well as the nitty-gritty details of the code, then Next.js is best.
But, if you want to template a site quickly, then it’s hard to argue with the plugin ecosystem that Gatsby has made and continues to grow among their community. (But if that sounds too good to be true, you may want to keep reading.)
Get Started with a Next.js Project
Following the last section, you may be thinking that Gatsby sounds amazing and that having a lot of setup done for you is amazing. That is until it’s not.
Because the approach that Gatsby is often known for can be so reliant on plugins and other people’s work, troubleshooting a problem in the code can be a big pain for the developers. To get around this issue, you ideally need to fall into one of two categories:
- You don’t mind waiting for other people to resolve a problem and push out an update, meaning your website potentially has errors and problems for longer.
- Or, you don’t mind being active in the open-source community and resolving the problems yourself.
If you fit into either of those two categories then troubleshooting on Gatsby might be okay for you. But, if not, then it’s a good reason to consider using Next.js instead.
It’s true that you can apply a similar level of control over data sourcing and code in Gatsby, but if you’re already foregoing their awesome plugin ecosystem, my personal preference is to use Next.js, where I’ve found it easier to apply and understand this approach.
Simply put if you like being active in the open-source community or don’t mind waiting for fixes to be pushed out then Gatsby is great. Otherwise, in terms of difficulty involved with taking a custom approach and then troubleshooting, at least, Next.js is a better option.
Both Next.js and Gatsby update to support the latest React versions quickly, React 18 is a great example of this. You can use React 18 with both frameworks right now, even though React 18 is still in beta.
However, when it comes down to individual upcoming features in React, the difference between the two becomes a bit more nuanced.
Let’s take a look at the upcoming React feature, React Server Components. Next.js has already come out and supported the feature, which you can enable in Next.js 12 by using an experimental flag right now. They have even put a couple of demos together so clearly, they are interested in the feature and supporting it.
But, with Gatsby, there’s a lot less certainty out there. At the time of writing, I can’t find any official communications from the Gatsby team that they will or will not be supporting the feature in the next version of their framework. Of course, as we will see in the next section, server-based features aren’t necessarily in Gatsby’s DNA, so they may decide the feature isn’t for them. But the lack of communication does leave a shroud of ambiguity over the situation.
If you’re interested in React Server Components and think it’s something you might want to use, then it’s hard to recommend Gatsby over Next.js due to the lack of announcements.
Both of these frameworks support Static-Site Generation (SSG), Server-Side Rendering (SSR), and Client-Side Rendering (CSR). They also both support deferred static rendering but with one subtle but important difference in how they implement it. It’s this difference that might help you choose between Gatsby and Next, so let’s take a more in-depth look at it now.
The key difference in the rendering methods between Gatsby and Next.js is how they handle the hybrid rendering of pages on a server. Next offers us Incremental Static Regeneration (ISR) and Gatsby calls their offering Deferred Static Generation (DSG).
Incremental Static Regeneration (ISR)
Since ISR came first, let’s take a look at Next’s offering before we move on and look at Gatsby’s DSG.
ISR is a rendering method you can use on Next.js applications to create or update static pages after you’ve built and deployed your application. By using ISR, you’re able to use static generation on a page-by-page basis without needing to redeploy the entire website each time. We can generate static pages on-demand, as the user requests them, instead of all at build time.
Let’s take a look at an example of ISR in action.
If you had a large blog with 1000 posts, you may not want to statically build each one of them at build time due to the increased time it would take. But, if we used ISR, we could choose to statically render the most recent 100 posts and then have the remaining 900 posts render when they are requested by the user.
But, this isn’t all. Because we are using ISR, we have the ability to fine-tune our selection. If we wanted to increase our pre-generated static posts, we could. In a similar fashion, if we wanted to cut our build time down further, we could reduce the number of posts we statically generate at build.
However, there is a potential downside to ISR. Let’s imagine a shopping website with a static home page and item pages that are rendered via ISR. Because the ISR pages are taking the latest available data from an API, the item page could show “Out of Stock” when the home page shows “In Stock.” This inconsistency is because the home page will be using data from the static build, which could be days out of date compared to the latest data consumed by the pages that are generated later.
Whether this is an issue for you will ultimately depend on the context where you are implementing ISR. For example, our blog example isn’t dependent on the latest data from API so ISR would be okay here, but our shop example? Maybe, but maybe not.
It’s worth noting that Next.js recently announced a new feature, on-demand ISR, which is currently in beta. With this feature, you’re essentially able to tell Next.js which pages on your site to rebuild based on where updated content appears, essentially solving the challenge posed above. You can already give on-demand ISR a try with Prismic!
If you’re interested, you can read more about ISR here.
Deferred Static Generation (DSG)
Now, let’s compare this to Gatsby’s version, Deferred Static Generation (DSG). Gatsby does a great job comparing their DSG to Next’s ISR in this blog post. But, the key highlight for Gatsby’s DSG is that it uses the previous full build to supply the data for the deferred builds that happen with user requests. And when data updates, you can utilize a webhook to invalidate the cache of build-time data and ensure that pages are rebuilt and/or deployed with up-to-date content.
We saw the potential importance of this in our shop example above. By not using the same data as the static build we could have had multiple pages showing conflicting information. But, if we used DSG instead of ISR in that example, the pages would never be out of sync because DSG uses the same data for item pages as the static home page.
Choosing Between DSG and ISR
Ultimately, both ISR and DSG allow you to defer static generation of content on your website, but which is better for your scenario will depend on how established you need the feature to be. On-demand ISR from Next.js brings these options much closer together; however, it’s still in beta, unlike the functionality from Gatsby.
Finally, it is also worth mentioning that because Gatsby uses the data from the last full build, it is a more robust offering because the dependency on any third-party APIs is removed. With Next.js if any third-party APIs go offline as ISR tries to render a page, the build fails and you’re stuck with the previous successful build with out-of-date data. As mentioned before it comes down to how essential the latest data is for you.
TL;DR and how to choose between Gatsby and Next.js
In conclusion, both of the frameworks are a lot closer than they used to be in the past, now that Gatsby supports more server-side features like SSR and DSG. This in turn makes the reasons to choose between them harder to find. Ultimately, a lot of it comes down to project needs and what you prefer.
- If you have a strong preference for GraphQL or want a great opportunity to learn it, then go for Gatsby.
- If you want complete control of the code that sources and manipulates your data, use Next.js. However, if you want to template a site quickly, Gatsby and its plugin ecosystem are a great choice.
- If you take advantage of Gatsby’s plugin system, some issues aren’t in your control for timely fixes. If this is an issue, Next.js may be the better choice.
- If the latest and greatest features are important to you, especially features like React Server Components, then Next.js is the way to go.
- Finally, if you prefer having the latest data in your application, Next.js is catching up to Gatsby with on-demand ISR. But, if stability and consistency are more important, then go for Gatsby and its DSG offering.
At the end of the day, both frameworks are great choices and are being frequently updated, so give both a try and see which you prefer for your next project.