Gatsbyjs and Next.js are two of the hottest topics in web development right now. I see a lot of people on message boards and comments sections on YouTube asking about why you would choose one over the other. I’ve had my head buried in Next.js and Gatsbyjs world for the last 12 months, and I believe that makes me qualified to chime in on this discussion.
When it comes to using Next.js or Gatsby for your project, “the right tool for the right job expression” comes to mind. But don’t worry I’m not going to leave you hanging with such a vague answer.
- Gatsby and Next.js are both React frameworks and both provide SSR (Server-Side Rendering) out of the box (great for SEO).
- Next.js is less opinionated of the two, but has a steeper learning curve, less batteries included, which mean’s you’re more on your own.
- Next.js is arguably better for sites that have massive amounts of data that needs to update frequently.
There’s a good reason that people are comparing Gatsby and Next.js. They have a lot more in common than they are different. Therefore, let’s first take a look at what Gatsby and Next.js have in common, and then we’ll discuss their differences.
Gatsby and Next.js:
- Both deliver high performance out-of-the-box.
- They both give you Server-Side Rendering (SSR) and Client-Side Rendering (CSR) out of the box
- They both provide Static Site Generation (SSG) and Dynamic Site Generation (DSG).
- They both have code-splitting and excellent caching out of the box.
- They both offer page data prefetching. Gatsby does this automatically, Next.js has a
prefetchprop that you can use with their
Linkcomponent (for routing).
- They both provide automatic routing for pages, using their own router (Gatsby uses Reach Router, Next.js uses Next.js Router).
- Both Gatsby and Next.js can fetch data from Rest API’s and e.g. by using WordPress, Contentful, or Prismic as a CMS backend.
Out of the box, Gatsby and Next.js give you the best of both worlds when it comes to Server-Side Rendering (SSR) and Client-Side Rendering (CSR). SSR is great for SEO, and CSR is great for giving your users those glorious instant page transitions (without a page refresh) that reminds you of using a native mobile app.
I want to make it clear that the following is based on what you get out of the box with either framework, not what either of them could potentially turn into via customization. Both Next.js and Gatsby are highly flexible.
Gatsby and Next.js can be customized “infinitely”. They’ll both go out of their way to tell you this much. The classic phrase “wanting to be all things to all people” comes to mind. Neither of them want to eliminate potential customers, and as good business people, they focus on highlighting their strengths rather than their weaknesses. As they should.
Neither of them are lying, but because both Next.js and Gatsby are so flexible and constantly evolve (with huge financial backing), it’s hard to say that one tool is better for a specific use case than the other when you talk about the long term.
I have no skin in the game, so this is my unbiased perspective. The main areas that make Next.js and Gatsby different:
- Gatsby forces you to use GraphQL (opinionated), with Next.js it’s optional.
- Gatsby handles image transformation out-of-the-box (somewhat opinionated) although you’re not forced to use it.
- Gatsby adds lazy-loading to images automatically (opinionated)
- A Gatsby site can be turned into a Progressive Web App (PWA) by installing a tiny plugin. I haven’t seen any simple ways of doing that in Next.js.
- Next.js offers both dynamic and static routing. As far as I can tell Gatsby only offers static/hardcoded routing. I’m not 100% sure about this one as it’s hard to find clear info (I’ll update this when I know more).
- Gatsby does its SSR during the site-building (SSG) phase.
- Next.js does its SSR dynamically on page request — but they also offer SSG via their static export feature.
As for customization, Gatsby has a ton of useful plugins that are mostly straight forward to install (from Comments to Algolia for search). Next.js has an /examples directory in their GitHub repo that showcases different libraries (“plugins”) in-use with Next. But in my experience using the Next.js examples are harder to configure than using Gatsby’s plugins.
Although Gatsby is statically generated out of the box, Gatsby can query various server API’s to dynamically fetch data.
Next.js can do dynamic data fetching in a similar fashion.
If you need SSR you can use Gatsby’s built-in GraphQL API to consume data from a CMS like WordPress or Contentful (“Headless CMS”) and then use a webhook (from your CMS)to handle auto-deployment every time you publish content.
In general, Gatsby is the more opinionated of the two. The upside of that is that you have less decisions to make. Next.js requires more configuration to get up and running. The upside of that is that nothing is forced upon you.
Next.js is more of a “build your app from the ground up” product, with some nice batteries included (SSR, routing, prefetching, code-splitting).
Gatsby is more of a “your starting point includes things that you probably want anyway” product, with many batteries included (GraphQL, prefetching, SSR, code-splitting, lazy loading, image transformations).
If you need pinpoint specific customization for every corner of your product, Next.js is the better choice of the two, simply because it’s more “barebone” (less things are done for you) out of the box.
It’s never fun to start a project by removing features from a framework, so if you don’t like GraphQL (for whatever reason) then Gatsby is not for you.
GraphQL is all the hype right now (for a good reason) which makes it hard to argue against Gatsby making it a part of the framework. I consider it a bonus, but your preferences may differ. It’s worth noting that Apollo (a GraphQL engine) is one of the most popular additions to Next.js apps.
As for Gatsby handling image transformations and lazy loading for you, while opinionated, the massive performance boost this gives you, will probably make you forgive them for deciding that for you. But again, perhaps you want to handle image transformations in your own way, and in that case Next.js is the better choice.
Since both Gatsby and Next.js are server-side rendered out-of-the box, they are both excellent choices for websites that need great SEO (Search Engine Optimization) — which means pretty much all public websites nowadays.
However, there is a certain SEO use-case where Next.js shines compared to Gatsby:
If you’re building a platform like Twitter or Reddit, where you constantly need to push content updates — and if you need optimal SEO for all your content — then Next.js is your best option.
How come? Because Next.js can dynamically server-side render content updates from your own server, instantly whenever there is a change.
For Gatsby to display new content, you have to rebuild and redeploy your app every time there is a change to your content. This is fine for blogs, eCommerce sites, and most other types of websites that only need to push updates once per day, or even once per hour.
If on the other hand your Gatsby site is dynamically fetching data from an external API to display updates on your site (e.g. via a comments service like Talkard or Disqus) then you can get real-time content updates on your Gatsby site — but you won’t get the SEO benefits, because the updates will be client-side rendered — not server-side rendered (which is what you want for SEO).
Bigger companies with larger sites tend to use Next.js as opposed to Gatsby. Although don’t get the wrong idea, ReactJS’ official documentation page uses Gatsby. I’m just talking about what I’ve observed.
Big websites that use Next.js:
- Uber Marketplace
- Material UI
Big websites that use Gatsby
Yep, interestingly, Marvel uses both. They use Next.js for their main site, and Gatsby for their MarvelApp (a design platform).
As for blogging, I’ve seen only a few decent Next.js blog examples but I’v seen quite a few good Gatsby blog examples. This one by Tania Rascia is one of my favorites.
While Gatsby makes it clear that they don’t want to be seen as “just another static site generator for bloggers” (like Jekyll), this doesn’t change the fact that it’s really popular for blogging, and many WordPress users are moving to Gatsby for that reason (including Tania that I mentioned above).
A lot of developers are talking about the trending “Headless CMS” or “Decoupled CMS”, where you’d use e.g. WordPress as the backend and then use React (or Angular/Vue) to consume data via the Rest API/GraphQL. Both Next.js and Gatsby can be used as the frontend app for Headless CMS products. It sounds very promising in theory, but so far I’ve only seen a few good examples:
- Next.js + WordPress by Kata.ai
- Gatsby + WordPress by Chase McCoy
- Gatsby + WordPress by Indigo Tree
- Gatsby + WordPress by Adam Rasheed
Adam and Chase’s Gatsby + WordPress examples are both really fast. As for Kata’s Next.js example while the website is beautiful, it’s a bit slow. Since high-end performance is one of the main selling points of Next.js, Kata is not the most convincing example of why you should use Next.js with WordPress.
Headless CMS is still a relatively new concept. There’s no doubt that Headless CMS’s in general (not just Headless WordPress) is going to be a hot topic in 2020 moving forward. And since both Gatsby and Next.js handle SSR for you, they are both solid options as your Headless frontend.
Since Gatsby is statically generated (prebuild) before deployment, it can run anywhere without it’s own server. Generally Next.js requires a Node.js server to run unless your entire app is exported as a static site, just like Gatsby is. (yep that’s possible). Some hosting solutions are tailer-made for one over the other.
Gatsby and Netlify are a match made in heaven. If your site is serverless, deploying a Gatsby site to Netlify can literally be configured in less than 30 seconds.
From here on contintius deployment can be boiled down to running a single
git push origin master command in your terminal — if you use gatsby’s gatsby-plugin-netlify plugin.
Next.js pairs well with the Now hosting service, and for good reason, Zeit is the company behind both Now (the hosting service) and Next.js (the framework).
Just like with Netlify, deploying to Now can be done in a matter of seconds, but it depends on what type of app you’re deploying.
Note: although Gatsby and Next.js pairs well with specific hosting services, you can indeed host a static/frontend Next.js app on Netlify (here’s an example), and you can host Gatsby on Now (here’s an example).
Both frameworks can be hosted on DigitalOcean, Heroku etc.
If want to host your own backend server/API (as opposed to going serverless) for either a Next.js or Gatsby app then you’ll want to look at something like DigitalOcean, Heroku, or Now. Beware that (“as of Now”) Zeit’s Now v2.0, they no longer support Docker, which is a dealbreaker for a lot of developers.
There’s delay between updates when you rebuild and re-deploy Gatsby. How big the delay is depends on how big your site is. The bigger it is the more time it takes to rebuild and re-deploy. I recently build this site with Gatsby, and it takes around 2 minutes from rebuild to redeployment is done, and it’s a relatively small site.
Next.js doesn’t have this rebuild > redeploy > downtime problem. If you run your own backend server, your new content will update immediately.
This might not be a problem if Gatsby makes it easy to handle incremental updates without downtime/delay, but as of right now you’ll need to find a way around it yourself (e.g. with websocket).