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 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.
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.
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.
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.
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.
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.
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.