Roughly over a year ago, most developers had no problem when it came to choosing between Gatsby and NextJS, as both frameworks served a distinctive purpose.
When you needed a static website for blogging or anything else that doesn’t require making regular content changes, you’d choose Gatsby. On the other hand, if you needed to develop a website that supports server-side rendering, something like an online store, where you have thousands of items which you will inevitably have to change regularly, then you went to NextJS.
It was really just a no-brainer and life was smooth sailing.
However, back at the beginning of 2020, with the release of NextJS 9.3, the game has changed, as it started to support such features as the latest trends in static site generation.
The new build time methods that were introduced with the version enabled developers to create static sites just like they would using Gatsby.
So, will NextJS be the to-go framework that knows and does everything, making Gatsby obsolete, or is there still a use for the latter?
In this blog post, we will go over the basic features, weaknesses, and strong points of each platform and recommend the best practices so you can choose the best option for your upcoming project.
First of all, web development solutions has come a long way from its early days and, now, sophisticated websites that handle custom-built content easily. Lately, as developers and designers are doing everything they can to please both users and browsers to build faster and faster web applications, server-side rendering and static site generation have become pretty much commonplace.
As you may know, NextJS and Gatsby are at the forefront of these tech developments and developers have been debating quite a while for now.
Gatsby
Before getting into the details, let us briefly overview some Gatsby fundamentals.
This framework is known for enabling developers to build static sites with GraphQL and React that perform exceptionally well. It helps you compile your React apps to static HTML. The framework is known to have a large ecosystem of different plugins, starter projects, and themes, and it creates web pages that also score exceptionally high on various speed analyzers.
It’s safe to say that Gatsby manages to combine the best of what GraphQL, React, and React-router have to offer in a developer-friendly static site generator.
Developer-friendly so much so, that some developers even go a step further and call Gatsby the go-to modern framework for the front-end. And with the fast page loads and a wide palette of different features it offers (asset optimization, date pre-fetching, and so on), Gatsby set the bar high for its competition.
Gatsby Highlights
Without taking the time and speaking about each framework separately, here are only some of the most praised and most criticized features of each.
Plugins
Known for its extensive plugin family, Gatsby offers a wide array of Node packages that enable you to implement Gatsby APIs.
Just download them from NPM and include them in the main config file.
Take Gatsby Image, for example. A neat little plugin that resizes images and build time. This makes it easier and faster for smaller devices to load faster, as they won’t start downloading desktop-sized images.
The overall image optimization tool will make the overall user experience better as it will make the web app perform and load faster (thanks to the lazy-load feature, the speed is even more pronounced). It also “blurs up” your images to provide a seamless user experience.
Going over and talking about each and every Gatsby plugin would literally take forever, but you can rest assured, that Gatsby offers a plugin for 98% of instances. Are you looking for font options? Offline website serving, to Webpack bundle analysis, you can get a Gatsby plugin that will get the job done.
Themes
When it comes to themes, you have a similarly rich ecosystem, just like you have with plugins. Themes in Gatsby are easy to download and update, and allow you to share data souring, functionality, and even certain design features across projects.
For example, one of the themes that are used widely is called Novela. It sports impeccable design right out of the box and features MDX local file storage and Contentful cloud-based options.
To top it off, you can easily customize and extend the theme by overwriting certain React components and style themes.
Is It The Best Tool In Your Shed?
Gatsby offers great resources in terms of themes and plugins which allow professionals to abstract away certain features, data fetching, configurations, UI, and styles. These possibilities make the framework a go-to choice for smaller projects, smaller blogs, and portfolios.
The problem is, when it comes to larger, more demanding apps, Gatsby may suffer from several scaling issues and you might end up with a final product that’s slow and thus, inconvenient to use. Another problem can be the framework’s heavy reliance on GraphQL which makes Gatsby really opinionated among web designers, and might not be the first choice for most.
NextJS
NextJs is a framework used to build React applications with static optimization, a default page-based routing system, server-side rendering with data-fetching, page-prefetching and client-side routing, automatic code-splitting, built-in SAAS, and SCC support, and API routes.
It can be configured with the config file through community plugins and you can even modify the Webpack configurations to add aliases. It also supports TypeScript. In short, it offers a lot of punch in a small package.
To put it in simpler terms, NextJS is preferred by those experts who want to build websites that need to interact with the server constantly. And with the help of Single File components, Hot Code Reloading, and Automatic Code Splitting, you can come up with truly genuine and functional website ideas for your React-base.
NextJS Highlights
Now, let’s see what’s the bread and butter of the rival, NextJS. Here, we will also take a look at some of the negatives that experts often mention regarding this framework.
Static Site Generation
With the introduction of this feature back with the 9.3 version, NextJS supports static site generation.
Here’s how it looks:
If you define the dynamic route pages/posts/[id].js you will need to give NextJS two things if you want to build this statically.
- The first thing will be the list of ids that you need to support. You can use getStaticPaths for this purpose.
- The data for the pages generated are based on your ids. You can use getStaticProps for this.
Based on this info, the framework will create a page for each blog post id, and the fetched data will be passed by it to the external service to the component.
Later in the article, we will get back to this feature, as it’s highly important.
In short, NextJS doesn’t force you to use GraphQL or Rest but leaves your choices up to you. This allows you to mix and match your options when you want to render pages statically or use server-rendered possibilities.
NextJS – The Negatives
On paper, NextJS might look like the perfect choice, however, it’s also opinionated like Gatsby, only in other ways. For starters, The file-navigation it sports works great for both server-side and static rendering but it down’s allow users to have dynamic routes for client-rendered data. This can feel like a huge drawback, especially for those who have been previously working on React Router.
For instance, if you wanted to use client-side rendering for specific a route like /products/yellow-dress-1. NextJS won’t be able to pull this off. The only way the framework would do it is by adding other query parameters, for example: /product?productId=yellow-dress-1.
NextJS Vs Gatsby – Putting them side by side
So, let us dive into the real stuff – comparing these two frameworks from different perspectives. First, let’s get a better look at the similarities between the two.
The Similarities
- Great and Powerful Websites – Both of these frameworks enable developers to create well-performing websites that rank high from several different aspects (such as speed, UI, UX, and so on). In both cases, the websites that are built with them are highly SEO-friendly, since both use pre-rendered HTML.
- Developer Experience – The extensive documentation that comes with both frameworks makes them developer favorites, and highly praised by the online community. Both Gatsby and NextJS feature a shorter learning curve, given that you already understand the basic mechanisms behind how React works.
- Great Features – For example, both Gatsby and NextJS feature Hot Reloading – an option that most developers simply love. With these frameworks, this cool little feature comes out of the box. On the other hand, both come with Caching, Routing, Code Splitting, and Prefetching to complete the package.
- However, the similarities more or less come to an end here. As a matter of fact, NextJS and Gatsby are used for different purposes, and further down the road, we will explore your options where you should use one or the other.
Gatsby.JS – The Static Website Generator
For years, Gatsby has shined as the go-to static website generator, and even to this day, many developers consider this framework as their primary option.
As you may know, a static website is basically a series of different HTML pages with each of them representing a separate physical webpage. You probably remember the old days, where old sites didn’t really have clickable elements on them, right? Well, those are a fine example of static websites.
On these sites, different users will see the exact same content however, they won’t see real-time updates. A great example of this is a personal blog, for instance.
For the most part, the number of these pages is highly predictable, and the content changes rather infrequently, Gatsby is the to-go option for most developers. Why? Because this framework offers great support for several content management systems, databases, REST APIs, and GraphQL.
On this end, one of the key differences between Next and Gatsby is their approach to data handling.
The latter separates the website and the data. This means that not only developers on your team can edit data, but everybody else. Later, edits can be compiled during runtime.
This approach used to be widely popular, because all you had to do was connecting to a CMS with a plugin, and you were able to update data without any coding or programming knowledge. However, things changed.
NextJS – Think Big, Think Dynamically
For years now, whenever developers had to build a large website with a large number of users who will have their own accounts and interact with the content on the page, NextJS was their preferred option.
As these web apps have several users that can join at any time, building a static site during runtime is near impossible. Not to mention, the building time that Gatsby would require for this purpose alone would make it a bad choice.
Such large-scale sites need dynamic content that’s unique for each user. Server-side rendering can help with catering to the needs of the different accounts based on authentication, meaning that each user can see their content right after creating it on the website.
So, based on what we’ve said so far, it seems like a simple choice, right? If you need static web pages, you opt for Gatsby, and when you need something more complicated and larger, you go to NextJS.
Yes, you can do that, however, if you remember, even in the foreword, we’ve mentioned that things have changed.
To find out what, please, do continue.
NextJS – Joining The Static Site Bandwagon Since 9.3
It’s been a while now, and you probably know that with the introduction of NextJS 9.3 new data fetching methods were introduced to the framework that also enables SSG support or static site generation.
These are the “getStaticPaths” and “getStaticProps” which users can use to build static websites pretty much the same way they would with Gatsby.
As mentioned already above, these methods will enable Next to generate static websites with ease.
Essentially, this is what gives NextJs its edge over Gatsby – it combines the best of both server-side rendering and static site generation. With such features, Next can be a great option to build a highly functional eCommerce website with keeping some parts of the site entirely static (such as your contact page and/or shipping info), while you can use the server to render those pages that are heavy on dynamic content (like your product pages).
Hybrid Web Apps with Gatsby and NextJS
If you are a developer who wishes to build a hybrid web app where you may need data handling to the CSR and UI page rendering using SSR, you should know that Next would be your to-go option as it will leave Gatsby basically in the dust.
Why? Because Next can handle an app where you will have both SCR for logged in users and SSR for visitors. Most of the time, these pages will usually feature dynamic content so Next is automatically a more preferred option.
NextJS – Is It A Dream Come True?
From what we said so far, you might get the idea that Next is the alpha and omega of front-end React-based frameworks that can do no wrong and has all the features a developer would need for virtually anything.
It’s true that it’s not that difficult to lean toward Next since it supports both dynamic content and static sites, however, there are a few concerns if you wish to use Next in the future.
- Data Security – In these terms, Gatsby might be the better option since it takes only the required data from the source. It’s true that some developers might argue that Next lets API’s and CMS’s have private features, but still, data is still on the server leaving it in clean sight for exploitation.
- Infrastructure – With Gatsby, it’s enough to pre-render servers with databases on a build and use a CDN to start building fast websites. With Next, you need the time to set up servers with databases, maintenance, and so on.
- No Gatsby Images – We’ve already talked about this super little plugin that resizes the images during build time, automatically adjusting picture sizes to smaller screens. It also lazy loads the images, which means even more improvement in the speed department. Sadly, this isn’t available with Next.
Using Gatsby For A Large Website
So, do the features in the latest versions of NextJs make Gatsby obsolete? Not quite. As you can already see, there are a few advantages to Gatsby, from better data security to the rich plugin family.
Apart from that, there are also certain situations where Gatsby can even make a solid option for an eCommerce website.
Take this example here: you use Gatsby for a mid-sized eStore that sells phones, with around 200 products. The build time is reasonable, around 4 minutes.
This may sound counter-intuitive, however, when you know that the product catalog won’t really grow in the future, then the framework can be a reasonable option.
Also, in this specific example, developers don’t really have to worry about scaling either since the site can handle any amount of traffic because it’s only traffic data that’s taxing the pages.
Apart from that, there are certain advantages to this setup too. For starters, you have all the data history. If you auto build and deploy the site each time the data changes and store every older version in S3, you will always have the option of deploying your site with old data. This can be great if the new changes introduce a bug, you can always go back to a previous working version while you troubleshoot and fix the underlying issues.
In this, and similar cases, Gatsby does seem like a rather convenient option that gives developers enough space to update the website when necessary and to keep it running smoothly even if not everything is working as it should.
Putting it all together
Now, that you see the basic similarities and differences behind the two frameworks, it’s easy to see why NextJS clearly has the upper hand.
Next is extremely powerful when it comes to creating react applications, whether you are looking for an option for static sites or server-side rendering.
It’s the clear option for an eStore since you can use a fine blend of static and dynamic variables for different types of pages.
The framework also suits well both large and small websites, personal portfolios, and commercial projects.
The possible drawback for some may be the routing limitations of the framework, but once you get comfortable with that, you can build and scale different projects quickly and with ease with Next.
That being said, Next might be the better option, because most developers will argue that it can almost do anything Gatsby can.
On the other hand, some experts argue that the only thing that would make a fine addition to Next to make it even better is a plugin that works on the same principles as gatsby-image.
Even though this may be the case, we’re not saying that you need to forget about Gatsby altogether. There are certain instances when using this framework is a legit and convenient option.
Also, if you’ve been in the trade for a long time, you know that there’s no such thing as a perfect framework, so being familiar with both is probably the best way to get your own personal advantage by boosting your skillset.
