NextJS vs Gatsby
19 August, 2019 - 7 min read
In my last post I touched on some the key features of both of these frameworks, but today I'd like to make a complete assessment and discuss some of the critical 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 both excel at very different things and also 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 in that regard. I intend to provide some context so that you can 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 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. The reason primarily 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 so that you can 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. This SPA approach, while accessible, is not nearly as practical for search engine optimization (SEO). A site that loads the page already filled with a mass of relevant content and markup is at a significant advantage.
Dynamic Clientside Routing
With Next, 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.
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 as now you can infer a significant amount of safety just by naming your files with a
Under the Hood
Static vs. Dynamic
NextJS does not force your team to make the all or nothing decision about whether or not to completely commit to dynamic serverside rending or instead opt-in for a static page-based approach, so it can be applied to many more use cases than Gatsby can in my opinion.
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, but 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 also pairs very eloquently with AWS Amplify which 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.
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- pick the right tool for the job.
One of the greatest things Gatsby has going for it is the community of talented developers that have built a copious amount of ingenious plugins, themes, and starters to aid in your rapid iteration using Gatsby. 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.