Less than six months after I switched to WordPress, which comes seven years after I switched to Pelican, I’m boomeranging around, but this time using Jekyll.

So, why do this? Well, for one, I admittedly like to yak shave: I’m getting better, but even minor inconveniences sometimes send me on a spiral to gain an ounce of efficiency.

But a few months ago, I really felt WordPress provided everything I needed:

  • fairly performant
  • low maintenance
  • editable via mobile
  • easy to make changes from desktop (no Git workflow overhead)

So with all those advantages, that begs the question:

Why Switch? #

There’s a few reasons that rattled in my head, in these short few months:

Cool URIs Don’t Change #

Unfortunately, when I migrated from Pelican to WordPress, I ended up breaking every blog post URI. At the time, I thought this was a minor inconvenience for readers in the name of progress. Then I read Cool URIs Don’t Change.

It’s a short read, but the gist is simple: don’t change your URIs: there’s never a user-friendly reason to do so. Users will bookmark your good posts and pages, search engines will index them. The tools of finding knowledge on the internet are designed to refer to your content by a constant URI, so you break all of those bridges that are earned only by time by changing it.

It’s possible to build them again, but you start from scratch. With things like SEO, that can be difficult.

With WordPress, I was unable to get even redirects from my old URIs without installing a plugin, which was only available in the business tier. That’s slightly too rich for me, for the value it provides. Especially since redirects are extremely cheap to create.

Performance #

WordPress does a really good job with performance. But nothing beats static html with standard stylesheets. I wanted to have enough control over my blog that I could keep it slim.

Easy to maintain well after I’m gone #

This was one major impetus: longevity. Although I believe WordPress will be around in some form longer than I will be, I wanted to make it as easy as possible to run my site. Who knows, maybe people a hundred years from now might want to peruse it as some relic. Or maybe someone is still running into KeyError issues with Tornado framework in Python..

Static html will probably outlive humanity, so there’s a safe bet to double down on.

I have a fantastic text editor I can focus in #

This reason was one I wouldn’t have been able to predict. When I started typing blog posts in WordPress, it just felt… like high friction.

I’m used to editing Markdown files and using my editor for everything. When you take me out of that environment, into a new UI, with it’s own hotkeys, and it’s own idea of how to organize content, every thing was a learning curve. And on top of that, there was no way it would be as fast as my experience editing text.

In VSCode, I have jump-mode to navigate to any part of the document. I can quickly split panes to open multiple parts of the document at once. It feels natural to navigate around giant blocks of text.

And most importantly, I have hundreds of hours in my text editor, doing deep work. It’s easy to enter a flow state with my editor, and with any new editor I have to build that mental pathway. Files and text editing is a powerful primitive, and re-using your existing sharp tools is a huge plus.

Why Jekyll? #

As I regretted my switch to a SaaS product, I mused about going back to Pelican. But I decided to go with Jekyll, for a few reasons:

  • simple system to override templates and styles for my site
  • a strong community, as one of the first static site generators
  • lots of plugins to choose from

Overall, the experience has been good. Fairly simple to override behaviors as you need them.

One missing piece is providing pages of content to enumerate posts by tag or by category. But there’s a plugin in progress for that.

Auto-publishing from Dropbox #

One part I really disliked about my pre-WordPress flow was having to go through manually pulling and pushing changes in Git. A history of record is good, but the friction was very high.

So instead I added a directory for blogging to a shared Dropbox directory I use for my notes, and added a Github action to download content, and rebuild the site periodically. Now writing a blog post is as simple as creating a markdown file. And it gets synced to all of my devices.

The Dropbox mobile client also lets you edit Markdown files in the app, so it’s even possible to get some light mobile editing as well!

Conclusion #

I like re-doing things to some irrational level of perfection. But moving my blog to a static site built on a bunch of Markdown files has definitely improved my ability to write blog posts, and gives me the site performance and ease-of-maintenance I’ve been looking for.