DEV Community

Cover image for NextJS vs GatsbyJS - What's the diff?
Michael Friedman
Michael Friedman

Posted on • Updated on

NextJS vs GatsbyJS - What's the diff?

First off, thanks for taking the time! If you're interested in Next.js and the JAMStack in general, I've got a weekly newsletter, where I share the best bits of what I've been learning recently on the topic. I even dive into some other stuff like what I'm reading and things on the horizon. It's totally free for those signing up now, so if you're interested you can sign up at

During my last post, I touched on some of these frameworks' critical features. Today I'd like to make a complete assessment and discuss some of the essential differences and nuances between the two. Let me start by saying that this is not an opinion piece on which React framework is the best. While both of these frameworks could sometimes be used to hit the same target, they excel at very different things and have different costs associated with their implementation. My experience working with NextJS also runs more in-depth, so I'm able to offer a little more insight. I intend to provide some context to make a more informed decision when you are architecting your next stack. I believe that between the two of these frameworks, you can fulfill just about any user story.


What is it?

Next.js is a React framework that requires very little boilerplate to configure. Its most significant selling point is the serverside rendering (SSR) that it provides right out of the box. NextJS is developed by Zeit, which is an entire serverless ecosystem built on top of AWS Lambda. NextJS takes advantage of serverless technology to serve your application pages in a swift, reliable, and affordable manner.

Serverside Rendering

Serverside rendering is a topic on its own, but I will say that it's essential for almost any project where being found on the internet is of vital importance. Startups and tech giants alike are often opting for SSR when given a choice. This is because there is a tremendous difference in search engine indexing results for a single page (SPA) vs. SSR apps.

Have you ever used Create React App (CRA)? If you are a React developer, I'm guessing the answer is yes. Have you ever inspected the page source only to see the single div element that your application is rooted too? That's when you usually bust out the React Dev Tools extension to explore your application markup. Unfortunately, Google doesn't know how to crawl your application with React Dev Tools (although hopefully one day).

That only leaves the metadata for the search engines to discern what sort of content is delivered. While convenient, this SPA approach is not nearly as effective for search engine optimization (SEO). A site that loads the page already filled with a mass of relevant content and markup has a significant advantage.

Dynamic Clientside Routing

With Next.js, we render the markup with a Node service and return it to the client. There are many benefits to doing this, the big one we have discussed thus far is SEO, but there are also tremendous performance benefits to properly implemented SSR applications. Allowing a server (or function) to render your project, takes the most cumbersome work off the client, which almost always makes things a lot snappier. Next.js abstracts the process of code splitting, eeking out even more performance wherever possible in your bundle. That's all handled under the hood with some very sensible defaults that allow for easy customization.

Dynamic API Routing

One of the things that I love most about Next.js is how it handles dynamic client-side routing based on your application file structure. Even to those unfamiliar, it's incredibly intuitive. Rolling a proxy for routing an application like this is not an easy task, and Next does a genius job of handling all of this work for us.

The effectiveness of this API benefits significantly from the release of React Hooks. Now NextJS offers us a useRouter hook, which keeps our clientside routing even cleaner by not forcing us to nest our components in a higher-order routing component every time we want to make a clientside route change.

As of this latest major version (Next 9.0), we can use the same approach we do for clientside routing in NextJS on our backend. Just mkdir api in the pages directory of your project, and Next will build your API routes to match the folder and file structure, just like it does on the client. That makes pretty URLs and dynamic page generation easier than it ever has been.

TypeScript Support

NextJS will automatically support TypeScript files in your project. Also, equally important, the framework was just completely rewritten in TypeScript, which is a huge asset to the community. You can now infer a significant amount of safety just by naming your files with a .ts or .tsx extension.

Under the Hood

Already, one of the fastest-growing frameworks in the JavaScript ecosystem, recently, NextJS began receiving boosts of support from very talented members of the Google Chrome team, who are now working actively with Zeit and the NextJS core team to improve performance further. I think this is, in part, a testament to the firm belief that Google has in the future of NextJS, which certainly lends confidence to me when I'm building a project and considering using this framework.

Static vs. Dynamic

Next.js does not dichotomize the choice of dynamic serverside rending or static site generation. Generally, it can be applied to many more use cases than Gatsby.

Clientside Routing

Next.js uses a <Link> higher-order component to wrap anchor elements with additional functionality like the prefetch prop that uses an Intersection Observer to asynchronously fetch your data for linked pages before the client actually requests them. Still, it does so with these requests in a lower priority queue than effects that are executing on the current page, so there is no competition for network resources.


Next.js also pairs very eloquently with AWS Amplify. Amplify will handle authentication for you using AWS Cognito Identity Pools and automatically generate a GraphQL API for your backend and provision it using AWS Lambda, API Gateway, Dynamo DB, and CloudFormation. If all of those things are foreign to you, rest assured, that's the beauty of Amplify; it handles all the infrastructure so that you can focus on your API. That is what serverless and modern development is all about.


It would be unfair to categorize Gatsby as a static site generator and leave it at that. It behaves much more similar to a fully-featured dynamic React app than anything else.

Without additional configuration, Gatsby isn't set up for applications that handle dynamic data. It prebuilds all the HTML for your pages and links a JavaScript file to it, which is your React app. Any dynamic updates would require rebuilding your application. Gatsby's ideal use case is for projects without any changing data. It is perfect for landing pages, marketing pages, and documentation. I'll add simple e-commerce (small e-comm) sites that can effectively run from a cache.

While you can realistically build just about anything with Gatsby, it does not mean that you should. It's all about picking the right tool for the job, and it's my firm belief that you should use Gatsby for what it's best at which is static websites like the blog I'm publishing this post on, or documentation for OSS and other use cases that can primarily rely on cached content. Don't try to turn it into something it's not; static sites were never intended to deliver dynamic content.

One of the greatest things Gatsby has going is the community of talented developers that have built a copious amount of ingenious plugins, themes, and starters to aid in rapid iteration. However, the Gatsby docs do some comparing and contrasting of these two frameworks, and I think their chart is misleading and more marketing-driven rather than fact-based- so hopefully, this helps shed some light on the subject.

Top comments (8)

codercatdev profile image
Alex Patterson • Edited

Great comparison!

I have a Firebase NextJS tutorial starting soon if anyone wants to dive in little further.


I did my first terrible Livestream on it, but video tutorial coming soon.

michaelfriedman profile image
Michael Friedman

Cool, always nice to see more free educational content getting made for NextJS, especially with all the recent updates.

benzguo profile image

Great post!

If folks here are interested, I put together this tutorial on deploying a simple Next.js + Firebase app to ZEIT. (I've included lots of screenshots, so even if you aren't interested in creating a new project right now, you can get a feel for what working with these tools is like)

pavi2410 profile image
Pavitra Golchha

Thank you for saving me from Gatsby's feature comparison trap. I'm now using Next.js :)

chrisachard profile image
Chris Achard

Thanks for the comparison! I was just trying to decide what to really learn next for a static site; so this helped.

michaelfriedman profile image
Michael Friedman

Glad to hear it! šŸ™ Sounds like Gatsby will be a great fit for you and I think you'll enjoy using it.

xngwng profile image
Xing Wang

Totally agree. I see people misuse these kind of tech all the time because of grass is greener syndrom.

michaelfriedman profile image
Michael Friedman