Within the community of Linux users and fans, there’s a term called “distro hopping”, which refers to the act of constantly jumping around between different distributions, or “distros”, of Linux. A few examples of popular distributions are Ubuntu, Debian, Red Hat Enterprise Linux (RHEL), or Fedora. Back in the days when I ran Linux on my desktop as my primary OS, I was very much guilty of distro hopping, having tried out pretty much all of the popular distros at least for a short while. These days I’m using a MacBook as my primary computer, and thus macOS as my primary OS, so I haven’t been doing much changing around of my desktop environment, though I have undergone a few changes with my blogging platform over the past couple of years. So I guess you could say I’ve been blog platform hopping a bit 😛
It seems to me like static websites made a bit of a comeback in the past couple of years. With the rise of things like GitHub Pages, I find that today there are almost more static site generators than there are full-blown CMSs. Thus, I turned here to solve my problems. Static sites are by no means unhackable, but they’re certainly more difficult to compromise than a database-powered site. Not only that, but the performance is almost always better than that of a typical CMS which sometimes has to make multiple database requests in order to serve up a given page. Static sites aren’t perfect either though, and they certainly come with their own drawbacks as well. I began using a tool called Jekyll, which as I understand is the tech powering GitHub pages. Jekyll is a static site generator written in Ruby. I myself know little-to-nothing about Ruby, or its tooling, so I always found the setup a bit clunky and difficult. I also found it a bit annoying that I needed to install a bunch of dependencies like ruby, bundler, and gem to be able to produce my site. These dependencies would go on to just take up space on my computer as I didn’t use them for anything else. I didn’t really want to get too much into the template engine syntax (I think it’s liquid, but don’t quote me on that) either, so I ended up just grabbing a pre-existing theme and making minor CSS edits to it. All in all, my site felt sort of generic to me, and certainly not a great showcase of my skills and knowledge. I think it’s fairly obvious as well, as I made the switch sometime in late 2017, and had a stark decline in the number of posts I published throughout the rest of 2017 and all of 2018. I decided this needed to change though, so I had to make a choice: either figure out this ruby stuff and get comfortable with building my own unique site with a comfortable composing experience, or drop it altogether and replace it with another blogging platform. I went with the latter.
Initially, I was planning on just going back to WordPress. The writing experience in WordPress is excellent in my opinion, and I love being able to start a post, save it as a draft, and pick up from any device with an internet browser. I often like to start posts from my phone, usually as just a few bullet points or a couple of sentences to get some ideas in writing, and then elaborate on them once I’ve got a full keyboard at my disposal. With a static site, this is a bit more cumbersome, as I just have a series of files stored in a git repository, and I don’t particularly enjoy trying to manage git repos from my phone. Upon setting up my old WordPress site for reuse however, I discovered that the new Gutenberg writing system from WordPress only supports a limited set of markdown syntax without the use of plugins. On my site, I couldn’t even get any of the markdown to be recognized though, so all of my posts looked terrible in their published state. I don’t really want to go back and rewrite all of them to use HTML, nor do I really want to bother with attempting to import all of them and verify that the styles are good, so I abandoned this idea. I wasn’t thrilled about the maintenance headaches anyways, so I think it was a good choice for me.
With WordPress out of the picture again, I took a look at Pelican. Pelican, much like Jekyll, is a static site generator. Unlike Jekyll, Pelican is written in Python. I found this to be quite nice, as Python was the first real programming language I learned and used, and I had a bit of experience with Flask, so I was comfortable with the Jinja templating engine as well. Or so I thought. It’s actually been about 3 years since I regularly used Python for anything more than simple scripts, so I quickly found it awkward to do anything meaningful with my templates. Seeing as I don’t intend on becoming a full time Python developer, nor do I want to maintain any Python-related code for any reasonable amount of time, I ditched Pelican and moved on. Pelican seems great, and I have no complaints about it, but I’d prefer to use more tools that I use daily if I’m going to be needing to update my site even yearly.
There’s still one more problem I haven’t yet discussed with static websites that bothers me a bit – the lack of interactivity. Naturally, since there’s no database from which the contents of my posts are served, there’s no way to search the posts. On my Jekyll site I had a clever solution that I unfortunately can’t take credit for that involved searching through the site’s XML feed, though it always felt like a bit of a hack, and a limited one at that, as if I implemented paging in my XML feed, then that would have needed a fair amount of refactoring. Another related issue was the inability to have a contact form. I previously just used a Google form to get around this, but again, it was an ugly hack that to be honest I’m never sure even worked. I have some ideas to get around these two problems, but nothing I’ve finalized yet. As soon as I come up with something, I’ll be sure to publish a post about it though 🙂