Own Your Tools

I started this post with an alternate title: Switching Website Build Processor

On 2018-11-01, I cutover my website hosting from Wordpress to Github pages. This involved moving from a content management system to the static site building tool: Jekyll.rb. I wrote vaguely about this process in My Blogging Engine.

I switched from Jekyll to Hugo. What prompted the change?

Jekyll took ~66,000ms to build and serve the website on my machine; That’s 1 minute. Hugo took ~1,500ms; that’s about 1 second.

When I wanted to see a stylesheet change, I’d make a change and Jekyll would take 1 minute to show me the change. Hugo took 1 second. Hugo provides a feedback loop 60 times faster than Jekyll.

I found Jekyll for easier than Hugo to dive into. But the speed difference made learning Hugo worth it.

Build Process

In building my Jekyll site, I added a few additional steps after generating the base site. This was all managed through a series of rake tasks.

First, I ran a custom amplify task, creating an AMP friendly set of pages. This involved making a copy of each page and using the following:

• Nokogiri, an Extensible Markup Language (XML 📖)/HTML parser, to create or replace Hypertext Markup Language (HTML 📖) nodes; Removing the print stylesheet, transforming img tags to amp-img tags, etc.
• Regular Expressions to remove/replace strings
• Readlines and CSS Minifier to remove non-AMP friendly Cascading Stylesheet (CSS 📖) declarations then create a compact inline CSS
• ImageMagick for extracting image attributes
• And some other antics to ensure an Accelerated Mobile Pages (AMP 📖) compliant page

Second, I beautified each HTML document. Using htmlbeautifier, I created nicely tabbed output. I thought about using minified HTML, but found myself viewing the source as often as using web inspector tools. So I erred on the side of legibility.

Third, I again ran the CSS Minifier to create compact CSS for the non-AMP pages.

In switching to the Hugo (Hugo 📖) build process, I ported over much of this work. Keeping the rake tasks.

My new build process leverages the speed of Go for the heavy lifting of building the base site. Then when its time to publish, I run a series of Rake (Rake 📖) tasks written in Ruby to do the fine-tuning for publication.

Conclusion

By moving away from Wordpress, I’ve owned my website’s build process. When I found a faster component, I was able to swap out that component with minimal fuss, while keeping other build pipeline elements.

This process is analogous to the games derived from the Open Game License and the resulting plethora of system adjacent games and material. I found a system that worked for me, ran with it for a bit, then found something adjacent that improved my experience.

Most important, I did this all while maintaining ownership, through open source tools, of the entire build process.

In other words, make sure you own your tools.