Why I switched to Jekyll

As those who have followed my programming activities for a longer bit, they know I’ve used a custom site generator since 2016 - since I bought the domain and started my website. It has had many evolutionary steps over the years.

However, 6 years later, my mind had changed. From now on, I’ll be using a pre-made, maintained static site generator. But why?

Introduction

Looking at past iterations, the look of my website has changed quite drastically

Konsensus MkI

First iteration of MkII

Second iteration of MkII

All of these share same traits though.

All run from a homebrew system - mostly static generation, with MkII having a Go helper server to serve content bundles with additional JSON metadata (to allow for fastloading pages, a feature found since MkII). Content written mostly in Markdown, with the latest MkIII revision also working with Ruby files for dynamic content (example below). Code highlighting has also been supported from the start.

Latest iterations have inched towards containerization, by having been designed to be easily ran in a reproducible CI environment (e.g. Docker). One of the latest variants of Konsensus did indeed first run on AWS CodeBuild, and then on a self-hosted Jenkins instance on a Raspberry Pi.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# encoding: utf-8

require_relative './cv_page_helpers.rb'

ticket.name = "Curriculum Vitae"
ticket.pre_render_proc = CVPageHelpers::render_helper_proc
ticket.source = {type: "erubis", template: "main", file: "cv_template.erb"}
ticket.route = ['cv', 'en']
ticket.lang = 'eng'
ticket.menu = ['CV', 'English']
ticket.render_breadcrumbs = false

ticket.alternative_urls = [["about"]]

# Mark that this page has a nonstandard layout
ticket.extras[:nonstandard_layout] = true

Reasons to change

The reasons can really be distilled into two core reasons - all others I could think of boiled down to these

Maintenance burden

There’s no way around it. Developing software takes time, and developing good software even more so. Whilst I could certainly, with enough time, to make a site generator with every fancy feature I could ever possibly want, completely tested to the smallest corner case - do I want to?

Generator maintenance reduces the time I get to spend on other fun activities (programming or not). With the wide variety of decent generator software now available, the cost-value analysis doesn’t really work in favor of a custom generator.

Lack of learning and interest

Back when I first started my website, my skill level was much, much lower. At that time, a static site generator offered new experiences and feelings of success at a level I could achieve with reasonable effort. I wouldn’t trade away those hours spent experimenting, refining - they’ve shaped my programming habits and gave me experience I carry with me today.

Today, though? Compared to the work I do daily, a site generator is effectively mundane routine work. It doesn’t give me anything particularly new or interesting, and as such, is really just a chore to do.

It is no longer fun. And my website is meant to be a project for fun.

Why Jekyll in particular?

The current instance of my website will be running on Jekyll. Following reasons led to this particular choice