![](https://drupal.ampere.corrupted.pw/sites/default/files/images/gatsbyvsnext.jpg)
Gatsby versus Next.js
April 10, 2021 | TechWhen I started to think about recreating my portfolio and blog, I had two options for the front-end. There was Gatsby, which had just recently broken both of my Gatsby sites after updates. Since those update attempts, I haven't been really updating my sites anymore. I was frustrated by this because I aim to keep my sites up-to-date and secure. So I was looking for another alternative. I had been checking out Next.js, and I liked what I was seeing, so ended up installing Next.js.
After experimenting with Next.js, it got clear to me that Next.js might not really be that ready for use as a static site generator. Or at least it's not ready enough for me and my wishes. The server-side rendering felt good and I will definitely use Next.js in other projects I'm planning on starting hopefully soon. But on the static site side, there were many issues, and it just wasn't working well enough for me. So after noticing that Gatsby just announced the new major 3.0 release, I decided to try that out instead and give Gatsby another chance.
Documentation
I have always loved the documentation of Gatsby. Newbie-friendly, good and clear examples. I was a bit disappointed to notice that for the new features, the documentation just didn't feel as good as in the past. I had to use a lot more Google than in my last project, which is not the end of the world nevertheless, I felt a little bummed out because in my first Gatsby project I was just blown away by the documentation. They are still writing some of their documentation, and I know that they constantly have always been updating the documentation, so the documentation will most likely improve at some point. But I sent them a bit of feedback on some of the more problematic pages, hopefully, the feedback will be heard.
On Next.js the documentation seemed to be mostly fine. But it was not as good as the Gatsby documentation I had gotten used to. But now, thinking about the newer Gatsby documentation, the level is about the same. But both these documentations seemed to suffer a bit from the fact that they were clearly written by a person who knows how the functionalities work on a deeper level. The newbie-friendliness just wasn't there. Hopefully, both frameworks work on their documentation a bit, while remembering that there might be a person who is a first-time user.
Developer experience
Next.js was faster to use. Fast reloads worked just as expected, and the development process felt quick and responsive. The production build was also quite fast. Gatsby has always been quite slow to use, both in development and the build has taken a long time. In Gatsby 3.0, there have been improvements to these issues but the developer experience seems to be smoother and more convenient on Next.js.
Active menu items
On Next.js there was no automatic way to do this, but people had already created ways to do this, and all it required for me was some extra copying and pasting. On Gatsby, it takes practically no extra effort to achieve this.
Dynamic paths
The dynamic path creation seemed to work a bit more easily with Next.js than with Gatsby. I just needed to create a slug-based query (which I would have needed for Gatsby as well). After that, I just created a dynamic file for my articles. Quite nice and simple, no difficulties with this. So definitely a point for Next.js!
With Gatsby, I ended up using the old way of having a template file and adding code to gatsby-node.js. This is fine, but I would have liked to use their new File System Route API. But I just couldn't get that to work, might be just a problem on my end, but the documentation just wasn't clear enough for me to even understand whether I was supposed to, or able to, use that with my backend. But the old way works nicely, and that's the main point for me, I just need my dynamic pages to work.
Images
Next.js offers a nice image plugin that seems to work both easily and nicely. No complaints regarding this plugin's functionalities, lazy-loading was there, and similarly many other nice features. Compared to the old Gatsby plugin gatsby-image
I didn't feel much difference. Of course, my use cases don't take advantage of many of the possibilities of the plugins, my needs are quite basic. Gatsby has just released their new image plugin gatsby-plugin-image
. And just as they promise, the plugin is just superb to work with. Great new features and the plugin is very easy to use.
The issue I had with the Next.js image plugin was the image optimization loaders. They have Vercel, which works automatically and requires no configuration. And I understand that they offer the best functionalities when hosted on their own service. I was planning to use my own hosting, and that was problematic with the images. I wasn't willing to write a new loader or any extra code, I just wanted the images to work with no extra effort. After a while, I switched from my own hosting to Vercel's hosting.
The only issue I had with the new Gatsby's image plugin was that I had only image URLs from my back-end, not the image files. By writing a createResolver in gatsby-node.js I could create what the image plugin needed, and I could tap into the magic of the plugin. The image plugin offers StaticImage for the static images, and for dynamic images there is GatsbyImage. If you haven't yet used this plugin, I recommend checking out Laurie Barth's announcement and introduction of the plugin from GatsbyConf on YouTube. But on Next.js I could use the back-end image URLs in their image plugin with no extra work needed. So a point for Next.js for this bit! I understand why I needed to do the extra work with Gatsby because the GatsbyImage takes its settings in the GraphQL queries and for that; it needs files, not just URLs. Overall I think Gatsby's new image plugin is better than the one on Next.js. But the Gatsby team has put a lot of work and effort into creating the plugin, it's no surprise it shows.
Other plugins
On my old blog site, I had used gatsby-plugin-feed
to create an RSS feed of the blog. Next.js didn't seem to offer such a plugin. You could, of course, craft the feed manually... but I wanted to get this done automatically. If I had ended up with the Next.js front, I wouldn't probably have offered a feed. But now that I have the Gatsby again, I could just use the same plugin to create the feed.
Another plugin I missed having on Next.js was a sitemap. Gatsby has a plugin gatsby-plugin-sitemap
for creating sitemaps. It's really these small life-improving things that make Gatsby the excellent framework it is.
Gatsby also offers gatsby-plugin-manifest
for creating the manifest for your site. No similar plugin on Next.js. Gatsby's plugin creates most of the required icons automatically if you provide it with a big enough transparent icon. The plugin doesn't create the maskable icon that is needed for PWA. But the plugin allows you to manage the icons manually, which is what I ended up doing. So basically I might have just created the manifest manually altogether, as I did with Next.js. But if you're not interested in PWA, the automatically created icons by Gatsby are a nice feature.
Gatsby also has gatsby-plugin-offline
that makes the Gatsby site work offline. No plugin like this on Next.js.
I'm sure there are plugins that are better on Next.js than on Gatsby, but in my relatively simple use case, I couldn't think of any. These missing features aren't really that big of a deal, though, because most of these we can quite easily code manually.
Photo by Pankaj Patel on Unsplash