(This article is also available via the short link tomrei.ch/why-html)
When considering design decisions for my homepage, I decided to go with a very basic HTML approach. There are a number of reasons for this.
Before I continue, I want to acknowledge that my reasoning here is very specific to my use-case (which I hope to explain) and is not intended as a critique on the web as it stands today, nor the billions of users who rely on it. The modern web is an awesome feat of engineering, and a properly-designed modern website is a fantastic tool. I spend much of my professional time configuring and developing modern web services and sites, and I do enjoy tinkering with them. That said, for my homepage, I've decided to go with something more basic, and I've outlined some of the reasons below.
Web design in Web 3.0-land feels like a modern version of keeping-up-with-the-Jones'. Trends come and go, but when it comes to the web, they come and go a lot. It's annoying and exhausting. As a software engineer, I have no choice but to keep up with the trends, but for something I do for fun, it just feels like an extra burden without a lot of benefit. Perhaps if my job was as web designer I might be a bit more focused on having a showpiece portfolio site, but I'm happily employed and am more focused on making something functional.
My intent is to focus on content. The words (and perhaps accompanying images/media) are what counts here. Rather than spend my time trying to figure out why an image isn't lining up like I want it to, I'd prefer to focus on the actual topic I'm trying to talk about.
Using server-side technologies always seems to come with tradeoffs. Sometimes it involves a heavy-lift install of an application server (looking at you Java/.NET). Other times it's random, obscure packages that have different names depending on the OS and version of the software (looking at you, PHP). Either way, I don't want to focus a lot of time on these issues. Then there's the security implications. Keeping to basic HTML keeps the attack surface low. I still have plenty of legacy code that I'm still using relies on server-side stuff, so that's not going away completely for me any time soon, but I'm trying to phase some of it out where applicable.
My reasoning here is similar to the server-side stuff. Forgoing JavaScript eases development and maximizes compatibility. And while it's not really a requirement, as a retro-computing enthusiast, there's something satisfying about having a site that can be read on computers from as far back as the 1990s.
I have a ton of nostalgia for the early days of the Web as I remember it, when it was (figuratively) the wild west, filled mostly with other enthusiasts who were also tinkering and having fun. This is what I aim to do here. If it ever stops being fun and starts being a chore, I will know I'm doing something wrong.