DEV Community

Cover image for Gatsby vs Next.JS - What, Why and When?
Jamees Bedford
Jamees Bedford

Posted on • Updated on

Gatsby vs Next.JS - What, Why and When?

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!

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

huh?

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?

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
      }
    }
  }
`
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (71)

Collapse
 
dechowmedia profile image
Lucas Dechow

One thing I do wan't to mention (that sadly the article does not reflect)
Is the fact you can actually export your NextJS application as a static rendered app.

nextjs.org/features/static-exporting

And the documentation does also reflect this.
nextjs.org/docs#static-html-export

There are some limitations but generally you can copy just the dist folder and you have the app statically generated :)

(though there is some more to it, but it is not that hard, and pretty much reflects the same process as Gatsby)

Collapse
 
stackoverprof profile image
R.Bintang Bagus Putra Angkasa

sadly but true, after exported, dynamic routing like [somewhat].js path will not be working out-of-the-box :(

Collapse
 
dechowmedia profile image
Lucas Dechow

Hi @stackoverprof

Are you meaning that [somewhat].js is not working?
You have to precalculate the routes (or rather the possible outcomes of the route) for it to be exporting the specific pages - this is particularly done if the fallback is set to false:
nextjs.org/docs/basic-features/dat...

It will return a 404 (naturally) unless you specify the pages for export:
nextjs.org/docs/basic-features/dat...

If however you want to have some paths statically generated and then dynamically generate the rest (think a large ecommerce site, or blog/dynamic pages on a otherwise statically generated site) - you can use the fallback: true (as it will fallback to data fetching)
See this for more info:
nextjs.org/docs/basic-features/dat...

Thread Thread
 
stackoverprof profile image
R.Bintang Bagus Putra Angkasa

Thankyou

Collapse
 
ctrlsquid profile image
zach

This is honestly the best article I've ever read on Gatsby vs Next.js. Thank you for your contribution!

Collapse
 
jameesy profile image
Jamees Bedford

That means a lot. Thank you, my friend πŸ™

Collapse
 
trythesetips profile image
Adam

I started to learn JavaScript a few days ago and I keep hearing about these frameworks, the most common one I keep hearing about repeatedly is React.

Is there any framework that can make my "learning JavaScript" life easier from the start, and then also pay off later or should choosing a framework wait until I've properly learned JavaScript on its own?

Collapse
 
f94olivera profile image
F94Olivera

Don't focus on frameworks, first master vanillaJS, there're thousands of resources out there such as YDKJS by Kyle Simpson or Eloquent JS or flavio copes JS handbook. I suggest buying Traversy Media course on udemy of vanillaJS, after that continue with react then the backend, NODE + Express
Once you got the grasp of 1 framework the rest are the same, IMO they're always trying to reinvent the wheel...

PS:forgot about testing, after Frontend and Backend make projects WITH TESTS, i vouch for jest... in today's market this is a must

Collapse
 
leob profile image
leob • Edited

Hm partially agree, but not completely ... sure, VanillaJS is an important foundation to master, but if you then want to get good at React (and for good reasons, e.g. because the job market for React devs is huge and booming), well that's a whole new different world, you'll again have to climb a big mountain ...

The basics of React are simple but when you reach the stage where you need to know all of these prototypical 'patterns' (HOCs, render props, hooks, context, suspend, and so on), and when to use Redux (and when not), with all of its countless variations (thunks, sagas, whatnot) and 'best practices' ... welcome to a brave new world - React, simple to learn, difficult to master :-)

I just want to make the point that, yes, VanillaJS is important, but A Knowledgeable JS Programmer does not automatically A React Guru make ... it requires substantial extra effort.

Collapse
 
lucaskardo profile image
lucas kardonski

VanillaJS can replace most frameworks for building reactive static sites. If you get to master it, no need to learn React to make a simple site.

Collapse
 
iamaravindks profile image
Aravind K Subash

It is very important to learn the foundations.Once you master the foundation , you can switch to whatever the frameworks for your projects !

Collapse
 
degesis profile image
PovilasB

Go for vanilla, learn how to manipulate the dom, why jQuery is redundant, learn ES6, array/object methods. Then learn framework that is up to date and people are hiring for knowing it. Frameworks are like cars, everyone argues that certain brand is the best but learning to drive is what matters .

Collapse
 
trythesetips profile image
Adam • Edited

I'm now wondering what the most in-demand (from a hiring / salary perspective) framework is. My goal is to learn enough to get hired but I also want to ensure I have the best salary prospects at the same time. My initial thinking was that "full stack" development must surely be in the highest demand but now I'm thinking it might be smarter to really specialize in pure JavaScript and just one framework.

Collapse
 
danivijay profile image
Dani Vijay • Edited

TL;DR : strategy I followed = cover basics + interview questions, get a job, learn rest on the go. Choice is yours tho.

I was a php dev 1 year before. Took a break for 4 months, learnt basics of JS, Node and Vue, got hired for a reactjs position! Now I'm a full stack dev (react and rails!).

I may not be crazy good these (which is very difficult to become, especially in highly volatile js ecosystem), but brave enough to believe I can make things working with any of these tech. Personally I felt learning speed is much faster when there are deadlines and while working on projects that matters.

I'll highly recommend to follow twitter accounts of devs like dan abramov, where you can get lot of relevant info. Being up to date is critical to survive in JS world IMO. I also follows some sub reddits for webdev, js, react etc. YouTube tutorials of traversy media, academind and net ninja helped me a lot in the initial days.

Collapse
 
jameesy profile image
Jamees Bedford

So these are specifically React-based frameworks. A framework for a framework shall we say ;)

I would stick doing what you are doing for now - check out javascript30.com - when you get comfortable hacking together little projects then, by all means, check out a framework. I think actually it can make the process easier, but I wouldn't recommend doing so before learning the JS fundamentals.

Collapse
 
zuezs profile image
Tyron Allen

I personally would try and become an expert in vanilla JavaScript... es5 & es6+. Then learn how to serve it up with Node.js and Express. Then learn about webpack and Babel! πŸ˜ƒπŸ˜ƒ It will help you understand moving parts of JavaScript and eventually you should learn React.js library . (not a framework) and then Redux. πŸ‘

Collapse
 
lucaskardo profile image
lucas kardonski

This is the same problem I had. Whats the point of learning React/gatsby for making sites when you can make reactive static sites with vanillaJs that behave exactly like a native app. This will allow you to master javascript and a do the same that a react app does. Still theres cases where you might want to use React, but it’s overkill for a simple site/blog.

Collapse
 
thiagodebastos profile image
Thiago de Bastos

Hmm but isn't the point of something like Gatsby to have you up and running with a blog in a manner of minutes? Who wants to spend all that time setting up each time, the boiler plate can be overwhelming.
I suppose the question is: do you want to master JS or do you want to turn ideas into reality? Its a touch tight rope to balance and it depends on what kind of engineer you are how you are employed (eg solo/contractor/full time).

Collapse
 
ranjankumar666 profile image
Ranjankumar666

Please dont do that mistake, dont go with hype, try vanilla js especially the es6 and beyond syntax find out why u need to switch to react, angular, etc. If u dive in now, nothing will make sense at all and you will be in a complete mess

Collapse
 
dmytro_dmytro_dmytro profile image
Dmytro Dmytro

James, thank you! Most of us all the time say that NextJS fits big projects and GatsbyJS is for small. Nobody says why. You pointed out a really important thing: "...content to grow a lot over time, then static generated web pages are not the best solution for you". Basically, it's a truth. A truth that lives now. GatsbyJS community claimed to improve this long time ago and looks like the core team did few steps forward (Read on my blog: webman.pro/blog/is-gatsbyjs-great-...).

What if GatsbyJS team will implement incremental builds support? Can they fight NextJS in context of big application? IMHO, depends, because NextJS
and dynamic SSR will still be more flexible. Let's say your GatsbyJS application based on some global configuration and any change will require rebuilding anyway. What if you had 1 million pages? You would still have to rebuilt all of them with GatsbyJS, right? In case of NextJS you have to invalidate cache only (if you have such). For sure, cost of NextJS infrastructure is a bit higher, but we are not talking about money here :D.

Collapse
 
rodolphonetto profile image
Rodolpho Netto

I first came across gatsby and tryied to convert a wordpress site by its API the question is that it have more than 9000 articles (its not the vegeta's joke) it has not even builded. Them I found next.js and it solved the problem, now I'm build a institucional site with a little blog posts system and gatsby are doing the job perfectly

very nice article :D

Collapse
 
bayuangora profile image
Bayu Angora

How long is the build and deploy processing time? Have you try or compare it with Hugo?

Collapse
 
kosvrouvas profile image
Kostas Vrouvas

Would you recommend Gatsby or Next for a blog with the expectation to scale to 300 or 400 posts over the next one to two years? I'm developing a new website now that already has around 130 and takes about 5 minutes to build on Gatsby.

Collapse
 
jameesy profile image
Jamees Bedford

My personal instinct would be to go with Next.

Collapse
 
nham profile image
Nick • Edited

If you still want to pre-build larger websites, site generators like Hugo and Nift still have surprisingly good build times on websites with thousands of pages or just lots of content. You can use React with at least Nift as well.

Collapse
 
alfanzain profile image
alfanzain • Edited

I have working on Next.JS project and I hate it.
Annoying routing. Annoying deploying.
And I really don't understand what is the difference between dynamic and static on this context.

You said, "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."

It means that Next JS generate static web page when 5 school page when data from API just have 5 school data, and when data from API increased to 100 school Next JS generate static web for 100 school?

Plus, annoying deploying.
I have VPS with apache (only. my nginx is crashed) and it's SUPER difficult to deploy Next.JS project. So I am forced to 'static export' the project.

Collapse
 
adeyemiadekore2 profile image
korey πŸ‡³πŸ‡¬ • Edited

Tried out Gatsby recently, it's really awesome, hoping to go into next.js soon.

From the authors explanation that next.js involves generation of content from the server. In terms of performance making round trips to such server and getting our content would have to affect the speed of such application. I think that was why client side rendering (CSR) was introduced in the first instance.

Well unless we introduce some caching, but still our app would still be slower initially.

I guess we have some pros and cons.

Collapse
 
douglaslondrina profile image
Douglas Schmidt

Not necessarily. Rendering on the server-side has the benefit of less back and forth between the client and server as requests have to be made to bring content, so it could actually be potentially faster.

And as you mentioned, server-side rendering makes caching and working with CDNs a lot easier.

Collapse
 
fazlulkarimweb profile image
Md Fazlul Karim • Edited

Next can now both of the things. I started using Next.js. Never looked back.

In Nextjs
export const getStaticProps = async () => { // getStaticProps for SSG, getServerSideProps for SSR
const data = await fetchData();

return {
props: data,
};
};

IN GATSBY
export const query = graphql
query {
site {
siteMetadata {
title
}
}
}

Rest of the codes are almost same.