To Make a Blog Usable

August 19, 2026 · meta, web


Intro

I've had a few iterations of blogs and sites over the years. Turns out, the less you use something, the more difficult it is to keep it working the way you want. I'm going to spend this post talking a bit about the types of technologies I went through, and where I am now. Maybe this helps someone build something sane, that may need to sit idle for years at a time.

Some Requirements, or "Why Not WordPress?"

My biggest requirement for my website was to be lightweight. I'm not particularly interested in a million WordPress plugins, and really just offers me attack surface for no benefit. Could a website that just works really be that hard?

Of course, this is a little hypocritical - you've probably noticed my website is pretty stylized. But at the core of the site, it's a rather simple framework that delivers text in an orderly fashion. Which brings me to my next requirement...

My website should be customizable. That's the whole point! I'm not here to use a platform that lets me pick a few colors out of a palette for their UI. I want full control over how my site looks. In this sense, I want to build a website, not just inherit a structure for my blog post.

The website should be extensible. I don't want to lock myself out of the million potential features that WordPress offers. As much as I love my simplicity, sometimes I like features too.

Finally, the website should be stable. Surprisingly difficult! I noticed a trend that any website I could host on another platform that handles things for you, WILL be deprecated eventually. That'll be a headache.

Jekyll on GitHub Pages

When I tried this almost a decade ago (horrifying), this was what everyone was talking about when you look up a lightweight blog. This was also my first static site generator (SSG). SSGs are fundamentally exactly what I'm looking for. They are close to the bare minimum to stand up on a server (often just whatever HTML/CSS/JS you want), while also offering a good way to write posts and pages in a simple way (Markdown). In fact, this approach would've been exactly what I use today, if it weren't for the actual mechanisms behind hosting on GitHub.

To me, hosting an SSG on GitHub was a harrowing experience. Practically every time I wanted to make a blog post, I'd clone down the repository, and find some issue with the SSGs build environment that just didn't work. Sometimes GitHub's ruby implementation was out-of-date, sometimes Jekyll stopped supporting whatever version GitHub was using, sometimes the version they both supported wasn't supported any more on my machine's repositories. I often spent more time trying to get my environment to function than I did actually writing posts.

Look, I'm a sick freak and truly love fixing obscure software issues, but this is too much even for me. Just let me write the damn post, man.

Substack, Neocities, Tumblr, Etc.

There's a genre of site I like to think of as a "custom page container". Substack less so than this, but Tumblr fits the bill if you think about it. If a platform just needs to be customizable with web technologies and make posts, why anything else?

Well, for starters, I like my domain. I like it when people visit lordnet.sh, and I feel awesome linking it. Plus, it was around this time that control started becoming one of my concerns. By this point, GitHub was almost down more than it was up. Why subject myself to the uptime of another entity? Especially small fry (all due respect) like Neocities or such.

Also, if we're talking polish, Substack crushes the rest in this category. But it's way less customizable. Also it looks like twitter, eh.

I'd like my projects to exist in the same space as my posts, too. When I considered these platforms, I had to concede that my projects would live on GitHub, and my posts would live on another platform. This segmentation, to me, is just ugly.

Just a Web Server (Who Even Needs CSS?)

Don't do this. I know I look stupid for mentioning it, but genuinely after wrestling with Jekyll and being dissatisfied with the more streamlined solutions, part of me just wanted to throw HTML onto a web server and call it a day.

It should be obvious why this is a bad idea. Who has to organize it? Me. Who has to make sure every post is referenced? Also me. Not even to mention designing it, if you want it to not look like a 70 year old CS professor's .edu page. Not that there's anything wrong with that. Full respect to that.

Something that's less obvious about this approach is that it's way harder to use as a portfolio. If you want to consolidate your projects and posts into one platform, you need to remember that some HR department that wants to hire you should be able to navigate it. Way harder than it sounds! If any HR departments are reading this, this is not an insult, engineers genuinely cannot build software to accommodate normal people. You need to yell at us. Building for non tech people is a whole skill to consider.

The Stack I Landed on: 11Ty on My Own Hardware

It might sound a little silly to go from "Hey you don't want to build it yourself" to "Hey just build 90% of it yourself" - but I promise it's way easier than it sounds. If you're willing to throw together a little CSS (the worst part), your SSG of choice will practically do the rest for you.

If you don't have your own hardware, a cloud device will do just fine. But I'm honestly in love with the way my stack looks right now. A little bit of elbow grease in, and I have a Forgejo action (GitHub actions for people who like stuff on-prem) that automatically deploys it to my web server.

The flow is easy now that it's set up. Write a blog post, git commit, git push, done. The automations handle the rest. 11ty is configured to automatically generate what I call the "boring" variant of the page, where normal people don't have to look at my goofy phosphor website. It's linkable to us dorks and well-adjusted individuals alike.

My projects and posts exist on a page that 11ty generates as a collection, meaning when I upload blog posts or projects, it'll populate those lists, and list/organize them accordingly when requested.

The drawback? It's work, man. Ignoring the strange layout of the main site, I had to string together a lot of boilerplate for the 11ty logic to handle a lot of this stuff for me. Not for the faint of heart.

But hey, at least I can guarantee that 2 years from now, GitHub won't throw a fit based on what ruby version my blog was written against.

Epilogue

If you host any of your own machines, I super recommend this flow. I use 11ty to build my website, Forgejo to orchestrate the build, and Caddy to host the output. The beauty here is that any of this stack can be swapped out. You don't even need to have a GitHub actions equivalent to build it, I just found it convenient.

But if you were interested in hosting all of your data yourself, I highly recommend it! It's not a very heavyweight process (besides the orchestrator - again optional).

Expect to see more posts from me as I've made this exponentially easier. I've also added An atom feed here. I'll be adding a subscribe button alongside the commit that builds this post, stay tuned!


← back