Gatsby is a free, open-source, static site generator that harnesses React Static site generators are software applications that create static pages from a template or component and supplement them with content from a source. This can be best explained with a diagram:
Gatsby can ingest content and data from wherever you can find it: APIs, CMSs, databases, local files. Gatsby ingests these data points into it's data layer. Once data is pulled into Gatsby, your pages and components, both of which are built in react, specify what data they want to access through GraphQL queries. Gatsby run these queries and supplies your templates with content. The resultant HTML, CSS and JS are then ready to be served to your visitors.
This all happens at build time meaning its...
This all happens at build time. Every route is prerendered and therefore is static content. When we say static content we mean that the content does not change for each visitor and its content is not dynamic. There is no computation neccessary - it always serves exactly what is stored.
Blast from the Past
Although the approach is old-school - it has some real benefits that I would like to run you through. While I will be focusing on GatsbyJS, most, if not all, of these apply to all static site generators.
Advantages of Gatsby
- Speed: It's hard to beat the speed of sending static output. As we've already discussed there is no thinking or computation needed before the files are sent.
- Percieved performance: The content becomes visible far sooner when using static site generators as you can see from this diagram.
- Scalability: Gatsby is designed to scale. It's easy to add more pages and components to your site.
- Security: Gatsby is designed to be secure. It's easy to secure your site.
Though not always as important to the client, having a tools that your developers find easier to use should always be considered a bonus. Using Gatsby we can remove logic we all find pernickety like routing, progressive image loading and data fetching. Documentation is also among the best that I've seen.
It's also really important to remember that just because you're using a static site it does not mean that your site pages have to be static or any less interesting. This presentation deck was built in Gatsby and I'm sure you'll agree there is nothing boring about it.
Up until version 4 of Gatsby these were the kind of sites that Gatsby really excelled at. But in September of last year things changed.
While Gatsby is my favourite, it is crucial to understand that it is not the only React static site generator on the market. The competitor most often uttered in the same breath is Next.js.
If we look at npm downloads over the last few months, you'll see that Gatsby has been consistently beaten by Next.js. Why is that?
Well, Next.js can deploy a static build or instead (and most often) a server. When a page is requested, this server builds that page and caches it before sending it to the user. This means that subsequent requests to the resource are faster than the first call. Which brings us on to the next point.
Sometimes Static Isn't Enough
Sometimes Static Builds are not enough, Server Side Rendering allows us to create better experiences paticularly for authenticated experiences.
It should however be noted that when comparing a Next.js server to a Gatsby static site, the intial page load will always be faster on Gatsby.
Without SSR, Gatsby was losing market share. It desperatly had to adapt to keep up. With the introduction of Gatsby v4, Gatsby pivoted from a static site generator to a full stack front-end framework. Introducing some great features like DSG and SSR.
If you're using DSG, SSR or functions you can no longer serve up a static
build as the server needs to think. So in the cases where these features are
used, Gatsby uses node to create a server to handle requests. Hybrid builds
are the best of both worlds - we should be using them more.
It should be noted that you can still create static builds without these features if you want to.
Gatsby wasn't the only one to change its thinking over the last year...
While Gatsby moved into SSR & DSG, Next moved into static site generation. Both frameworks now cover all bases. Both approaches have great use cases so it really does depend on the project.
But which one?
This might lead you to ask the question "which one do I use?" The answer is - either one is better than neither on projects that are suitable! One thing I will say is that image optimisation is better in Gatsby at the moment but this could change soon.