TLDR; Gatsby is good for react portfolio sites, but worse than NextJs for web apps and much slower to work and more of a hassle than Web Builders/CMS for brochure/primarily static sites.
For my current website, I decided to use a React-based framework called Gatsby. Now that I have finished my website to the point where I am relatively happy with it and it’s fullfiling what I set out to build it for (notice I didn’t say it was finished: a website is never finished), I find it adequate to write a short review!
What is Gatsby? A Quick Overview
Gatsby was initially described as a static site builder for React, but this description has been retracted by the developers. This is because Gatsby is more like “Create React App” (CRA) on steroids. Indeed, you can build anything with Gatsby that you can build with CRA, but it also adds some static site generation features, similiar to the popular framework NextJS.
However, Gatsby goes beyond this and also offers some plugins that allow for post build optimisations, when the website is compiled into static files. One of these key features is smart image processing, which reduces the need of an expensive third party cloud offering that provides a similiar service.
As with anything, it wouldn’t be fair for me to call this “the end all be all” review. I obviously had some hopes and expectations that I wanted to fulfill when using the framework, which were based on some basic research. As a result, I will be basing my review and experiences on my opinions, or specifically on how I felt Gatsby performed when applied to my particular use case. Here is a breakdown of what I expected when starting to work with Gatsby:
- A fast, static website (this was the most important thing!)
- Good developer experience
- Being able to develop quickly
- Improving my React skills
Data Fetching is easy, but REST support is poor
The data in Gatsby Node is handled using GraphQL, making it easy and convenient to assemble data from many different sources (provided they have a GraphQL API). REST could also work, but its not really as integrated with Gatsbys other features and little to no documentation or plugins. This is a bummer, because setting up a custom REST endpoint is still much easier than setting up GraphQL at the time of writing for this review. In addition, obviously there are still many data sources that do not support REST out of the box.
Another method that allows us to fetch data is called “static queries”, which is just used as a wrapper for normal GraphQL query and then assigned to some variable within the scope of the React hook. Now, I no longer need to query blog data from the Node file, since I can do it in the post component itself – you might think (as I did)!
The problem is: we can’t pass variables to these static queries, limiting their use – most of our data fetching will have to be done in the Node file. Also, if you were hoping to make static REST calls, you are going to be disappointed.
Image Processing is Powerful, but inconvenient
A core feature of Gatsby is its image processing capability. By querying the image with GraphQL, you can convert your image into a “fluid” format that will adjust to the size of its container. That image is first sent as a low resolution image for improved performance to reduce load time, then upscales within the client using a fancy fade-in animation. This completely avoids images that pop into the view, potentially shifting content, since there is no latency on the low resolution images.
In addition, the processed images can only be used in a special wrapper components provided by Gatsby. These take up the space of the parent component and don’t behave like normal images from HTML. For example, when defining a fixed dimension for the Gatsby image component, the entire image will simply disappear.
Hosting with Netlify and similar Services is dead simple
The title says it all: services that automate deployment by hooking up with your git are great with Gatsby. Takes almost no time to get up and running, especially if all of your data fetching is done during compile time since your site is almost risk-free of running into annoying problems with APIs and such. Add, commit, push – and have little to no concerns that your site will go down or run into problems.
The Plugin System is Great
My only problem with the system is that I found it to be quite confusing when to use a plugin or simply try to import and use the node module as usual. It can also lead to some confusion when using a third-party library and it isn’t working, only to realize that Gatsby requires you to install a plugin for it to work properly with the serverside rendering.
Heads up, although this was not a problem I faced: because of the compilation process, the headers of the Gatsby index.html file are reset each time. If you rely on importing something this way (like a remote CSS file), you will need to hope that a plugin exists or forced to write your own!
My biggest Problem with Gatsby
So after that feature review, you might be thinking: “well, that’s all pretty decent, isn’t it?” – and I’d agree! Here is my issue though: I’m not exactly sure who this framework is for. Obviously, React developers who want to build slick, fast portfolio sites are going to love this and perhaps this is the target audience. But beyond that, it can be hard to identify how Gatsby would be more suitable for a given use case than other options.
For example: the small, local business owner who might be interested in a a fast, static website is probably not going to bother learning React or hiring an expensive consultant with that skillset just to get a web presence. Tools like shopify, WordPress or other web builders are much cheaper, easier and faster options for this group of people. The truth is that even a lot of developers opt for these options over coding their sites from scratch, simply because of the fast speed (I found that developing with Gatsby is not really much faster than using “create-react-app”) and lower hassle of getting that site up and managing it.
Then there is the bigger, enterprise businesses or smaller, independent SASS providers. These certainly have interests in leveraging cutting edge technologies that single page applications and progressive web apps provide. They are also able and willing to spend that extra buck to hire professionals for having that extra speed and customization.
The big problem: NextJS also offers static site rendering and while it does not provide many of Gatsby’s performance optimization tools, it does have an advantage that is extremely significant. This advantage is that unlike Gatsby’s data fetching tools, which are not very dynamic, NextJS allows user to inject data into the static build process on the fly, which is ideal for web platforms on which the data is constantly being manipulated by user activity and other forces. Gatsby takes a long time to compile and spit out the static files, whereas NextJS is built to allow for this dynamic data insertion.
I’d also love to see a future where we can just plug in a normal image tag and have all those image processing features out of the box. Maybe that is a bit idealistic or something left to the browser creators/large companies, but it would be a huge improvement over the current workflow nonetheless. The same applies to how limiting some of the static data fetching capabilities are.
Besides these flaws, I learned a lot from building my first Gatsby site and might have a look at it again in the future, perhaps with some of these aforementioned changes. I’m giving it a 7/10, 4/5 stars, “pretty deece” – I think you get the idea. Thanks for reading this review, hope to catch you for the next one!