Thought process for an SSG

Posted on
data-science

I spent a lot of time researching different solutions for a blog before deciding to keep it simple. I was obsessed with a few qualities that I later decided weren’t important.

These qualities were:

  1. Static site on first load
  2. Allow JavaScript to be turned off
  3. Evolve into a progressive web app with asynchronous loading

I used this site to find and compare different solutions.

In particular, I’ve evaluated: Cryogen, Jekyll, Next, Gatsby, and Hugo. After trying to use Next and Gatsby I decided that they were just too complicated and my new list of important features became:

  1. Static site
  2. Allow JavaScript to be turned off
  3. Ease of use
  4. Will be maintained in long-term future

Based off of #3 I immediately removed Next off the list, and the combination of #2 with #3 removes Gatsby. I think those frameworks are certainly good, but for what I’m doing they are overkill. I was tempted to not look at Jekyll either because I’ve had horror stories with RubyGems, but for the sake of science I’ll actually include all projects on the Static Gen site (including Next/Gatsby even though I won’t be picking them).

I’m remarkably horrible at decisions so I turned this into a neat data science project so that I could have data tell me what to do. I wondered if I could find out how many projects on popular code sharing sites were using Hugo and the overall complexity of each project. Finally, I wondered if we could somehow predict the future popularity and number of contributers to the site generators as well as how active those sites will be.