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 michaels.blog

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.

NextJS

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.

Data

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.

Gatsby

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.