With Gatsby, this is all that’s needed to get up and running:
$ git clone --recursive https://github.com/andyet/blog.andyet.com.git $ cd blog.andyet.com $ npm install $ npm start
One of the main reasons we chose Gatsby is that it’s both a static-site generator and a complete React application. This gives us the performance benefits of static-sites along with the client-side performance benefits of single-page applications. When you type in
Moving from our previous static-site generator to Gatsby was actually surprisingly easy. We store all of our blog posts in a separate repo (hence the
To start, we copied over all of our style assets, written in Stylus. Thanks to
gatsby-plugin-stylus, we were able to easily reference our primary stylesheet inside of our default layout component. This ensured that our entire stylesheet was loaded at the root of the application. Our complete stylesheet is only 9KB gzipped, so it’s sent as an inline stylesheet with the initial document. This ensures that after the initial network request, there’s no other render-blocking network request.
Once we had our stylesheet being loaded, building the rest of the site was basically just copying and pasting the original templates, replacing template strings with their Gatsby-equivalents. Our existing templates were arranged in virtually the same exact way that Gatsby wanted, so the bulk of the modifications were simply replacing
className="" for React.
As was mentioned earlier, the most complicated portion of the transition was reimplementing two features our previous static-site generator gave us for free: related posts and archives. For related posts, we pick the posts with the highest “tag affinity”, which is basically the posts with the highest number of shared tags with the current post. We then add these related posts to our page context in the call to
Our archive pages were also pretty easy to build with Gatsby. We use a year-specific GraphQL query to get a list of all posts for a given year, and then generate a new page listing each of those blog posts. We then provide each page with a list of the years for which we have blog posts, and render a year selector at the bottom of every page.
In the end, the simple fact that our blog’s build process now mirrors the vast majority of our other projects is worth it in and of itself. Along with that, we get a UI system that’s familair to our entire team, the best loading experience from both static sites and client-side rendered applications, and the ability to grow and add other more complex features in the future like service workers.
So yeah, we think it was worth it!