The new version of Gatsby is available in beta and brings many improvements. How are they going to affect you and the development and maintenance of your sites?

In this article, I summarize the key new features that Gatsby v4 brings and explain how each of them will affect your daily work with a Gatsby site.

Gatsby v4 Improvements

Gatsby v4 was officially introduced and made available as a public beta last week during Gatsby Camp and it brought major updates:

• New rendering modes for pages
• Parallel query processing
• Improved Gatsby Cloud preview

Let's start with the first and see what changes for you.

New rendering modes for pages

Gatsby introduced support for two additional modes and now lets you use:

• SSG - static site generation = pages generated during a build
• DSG - deferred static generation
• SSR - server-side rendered

SSG is the original concept of static site generators, so let's start with the second one - the deferred static generation. It's not a new concept. We've been successfully using it with Next.js and Netlify had already introduced a similar improvement for other static site generators with their Distributed Persistent Rendering and On-Demand Builders. The idea is, you pre-build only the core parts of a large site and leave the rest to be generated and cached (stored) only after the server receives a request for a specific page from the first visitor. In other words, on-demand.

Having DSG now available in Gatsby is definitely a great improvement. In the past, it was challenging to use Gatsby for large sites as the build times grew with content significantly. Now, with DSG and Server-Side-Rendering mode (that we all saw coming with the introduction of serverless functions this spring), you now get full control over how each page of your site gets rendered.

However, there is one downside. From my experience, Gatsby is often used by beginners. Don't get me wrong - many of them are experienced developers, just not with JavaScript. And what they value the most is the low entry barrier. They could get a site up and running very quickly, they didn't have to read any docs as the GraphQL data sourcing allowed them to see every content that's available, and for anything extra, there was always a plugin.

While all of that is still true, the added rendering modes (SSR, DSG) require developers to make informed decisions that require them to learn more. The time they need to invest to see their new site live increases. And the same applies to onboarding developers.

Now, you may argue here that they would need to learn that with any framework anyway and that's true. But Gatsby, until now, was a perfect stepping stone into Jamstack on React. Just like Gridsome is on Vue. I've seen many agencies tipping their toe in the Jamstack water with Gatsby and the low entry barrier was the biggest attraction for them.

Note: See the full explanation of Gatsby's rendering modes in this video or in their docs.

Parallel query processing

Another great improvement towards decreasing the build time. It's actually not optimizing the build but distributes the computation of page queries to multiple processor cores that work in parallel. The Gatsby team made this possible by moving the content from the Redux store to LMDB that supports concurrent access. So we're getting better build time by efficiently using the hardware. Good thing is, you don't need to take any action besides upgrading to the newest version of Gatsby.

Gatsby Cloud preview update

If you saw my talk at Gatsby Conf this spring, you know that editors expect their CMS to generate previews of their content and they expect it to do it instantly. With Gatsby, this was made possible with incremental builds that took only a few seconds. Now, the Gatsby team took the preview experience on Gatsby Cloud one level further and implemented a UI panel that tells the editor in real-time that preview is coming.

Of course, apart from that, the Gatsby team is constantly working on differentiating Gatsby Cloud from other hosting platforms and now claims that it is capable of 10x faster deploys.

Kontent and Gatsby v4

If you're using Kontent by Kentico as a content source for your Gatsby site, you're probably using both of these packages:

• Gatsby Source Kontent Plugin Plugin providing data from Kontent REST API to Gatsby GraphQL model.
• Gatsby Kontent Components Package with React components that process Kontent data.

We've prepared the new source plugin version ahead of the Gatsby v4 beta release. However, it will be merged only after the v4 is fully released, so until then, make sure to check out this version of the source plugin.

The Gatsby Kontent Components package is fully compatible with both the current and the new versions of the source plugin.

Should I upgrade?

The presented changes have one thing in common - Gatsby is trying hard to enable large-scale applications. They constantly work on decreasing build times (which interestingly brought new potential with the move of the content store), providing options to avoid building everything, improving the Gatsby Cloud services, focusing more on the content editor experience, and working closely with strategic partners.

If your site runs on Gatsby, I'd encourage you to try out the new features as they solve the problems of the majority of sites.