Gatsby as an Application Platform

I’ve been thinking a lot lately about what it would look like to use Gatsby as the starting point for all apps, from more static things like this website to full-blown, complex, SPA applications. There is no question on the ability to do that, after all, Gatsby sites are still React apps once they load and hydrate in the browser. My thinking has been more around what Gatsby adds over something like create-react-app or a home-grown boilerplate for new projects. I’m going to start collecting my thoughts here.

Pre-configured tooling with escape hatches

Gatsby handles all the build config for you, so no need to configure Babel, webpack and all the plugins that go with them. In cases where you might need to customize something in the build config, you can hook into it and do what you need to do.

Plugins

Gatsby has an active community and as a result, there are a large number of plugins available. The odds are good that if you need to add some functionality to Gatsby, there is a plugin available that already handles the required configuration for you. If not, you can build a plugin for your own needs.

Themes

Themes are interestingly named. It sounds like something to modify the look and feel of your site or application, but in Gatsby terms, themes are far more powerful. Themes are essentially Gatsby sites that can be installed with npm to add functionality to your existing site. They’re composable, so you can add multiple themes to your site and your site will gain the abilities from all of the installed themes. This site, for example, is using a blog theme and a notes theme. Each one added their own capabilities under a specific path and now I have a blog and notes. And since it’s still a Gatsby site, I can build my own functionality, install more themes if/when the need should arise and if I wanted to add functionality to this site and several others, I could build that all into my own theme and install it wherever I need it.

SSR

Gatsby uses SSR (server side rendering) at build time to output pre-built pages that are hydrated at runtime to a full React app. For public, static-ish pages, this results in faster loads. For single page applications, you can pre-render some stuff and dynamically render the rest. You might not get the same amount of payoff you would see in a static page, but you get some and something is better than nothing when it comes to performance. If it’s built into the tool already, may as well take advantage.

Routing

Routing is built into Gatsby, using @reach/router. Code is split at the route level by default and Gatsby’s version of the Link component will start pre-loading the async chunks when you hover over them, keeping the initial load as small as possible, loading additional code on-demand, and doing it all in a way that makes the response times instant, or close enough that it feels that way.