Almost Two Years of Static Blogging

I thought I should evaluate how static blogging has been going after almost two years.

I’m generally happy with how the blog runs right now. Pages load very fast on desktop and mobile, which is what I like to see in a well-managed web site.

It’s hosted entirely within AWS (except comments), meets most all of my original design criteria from 2019, and costs about $2/month, which is an acceptable amount to waste on an obsolete social media model.

Hosting comments should be free, but I broke down and spent $20/year so I didn’t have to keep renewing the free domain name every month, which was a pain in the butt. I don’t love Remark42, but it works well enough for my purposes, more-or-less.

There are some ongoing “user experience” problems, though.

Images

Including images with blog posts remains a constant source of pain, every time I touch a blog post.

Part of it is unrelated to technology: I just hate finding a picture for every single blog post. Blogs posts are text. They’re supposed to paint a picture with words. But readers and, perhaps more importantly, blog-related aggregators expect there to be a header image on every post.

And from a practical standpoint, it’s a pain. I don’t write in a WYSIWIG editor: I write in Markdown in a plain text editor, the exact same editor I might use to write source code for programming (i.e. Visual Studio Code).

Therefore in order to include a picture in a post, I have to add the full Internet URL to that picture into the text of the post. I’ve built some shortcodes to reduce the effort, but I still have to type stuff; there’s no dragging and dropping involved.

Furthermore, the picture has to exist somewhere on the Internet before I can reference it. So I have to create and upload pictures before I can publish a post.

I’ve streamlined this process as much as I can over the last two years but it’s still a real pain and I hate it. It’s the number 1, 2, 3, 4, 5, 6, 7, and 8 reason that I avoid blogging whenever possible. (Reason 9 is that it takes too long to edit drafts, and reason 10 is that it hurts my back to write for very long.)

Publishing

Somewhat less annoying, but still a problem: I locked myself into publishing blog posts (and setting up images) only from one particular PC on my network, because that’s where I know all the scripts work.

I usually write posts as a “draft” first, which is a minimal Markdown file without too much metadata, just a title and tags. But to publish a markdown file with Hugo, it has to have a date added and be moved into a particular directory in your content structure.

Something I discovered very early on in this adventure: It’s extremely inconvenient to have to maintain the publishing date in the same file with your content text, before you actually publish the content. Especially when it might take weeks to finish editing a draft.

I also like to put the date into the filename of the markdown file, so I can glance at a directory of content files and know when they were written.

So I wrote a script that takes a markdown file as input, puts the current date on it, renames the file appropriately, and moves it to the appropriate content directory, ready for publishing. It saves me a lot of trouble.

But I only setup the script to run on this one particular PC. And I only have Hugo itself setup for testing on this one PC. So whenever I publish a post, no matter which computer on the network I write it on (I write most things on a Lenovo laptop that follows me around the house all day), I eventually have to go sit at this one PC to preview and publish the post, and I don’t like that.

I want to be able to run all the scripts and publish from anywhere on the network (especially the laptop), preferably on any platform, Windows, Mac, or Linux. Ideally I’d be able to pull down a git repo anywhere and publish from there.

But that will require some rethinking and moving things around, and, most annoyingly, rewriting scripts in perhaps Python instead of PowerShell. I don’t like Python and don’t know it that well and don’t want to waste too many brain cells learning it, but it might be a necessary evil.

Content Directory

I don’t regret dividing up my content directories by years and months, but I do regret dividing them by subject at the top level.

At the top level, my content structure looks like this:

• post
  • 2021
  • 2022
• gaming
  • 2021
  • 2022
• writing
  • 2021
  • 2022

My thinking was that people might only want to read one particular subject and ignore the rest. Unfortunately that makes it harder for me, because if I want to see what I wrote in, say, May of 2021, I have to look in three different places.

I should have left all posts together in one directory. Adding categories and tags in the post metadata would have been sufficient.

It’s fixable but unfortunately the top-level directory features in each post’s permalink, so I’ll have to setup a big list of redirects at some point, which was a massive pain with AWS Amplify. Or maybe I can fix it in the front matter metadata for the posts, I’m not sure.

Either way it’s a problem to kick down the road to a future time, until it becomes completely insurmountable one day.

But as we tick over into 2023, passing a very convenient data archive boundary, I might start writing everything in the “post” category to simplify things.

The Future

I’m happy with a static blog, but I’m also interested in some ActivityPub and IndieWeb features, which are impossible to implement in a static blog. So I might start migrating to a VPS (virtual private server) solution in 2023, which will dramatically increase the cost and complexity of hosting the blog. (By which I mean it’ll go from $2/month to something like $6-10/month.)

Something else I haven’t quite worked out yet is how to consolidate all my Internet content in one place. It would be nice to be able to have a central repository of content which can be viewed in different ways from different domain names. But I think that can be accomplished with a VPS and a clever nginx config file, so there’s another reason to move to a VPS in 2023.