For many years, until 2021, the idéemarque* website was my own static HTML hand-written codebase, which had the advantage of performance and flexibility (vs “what a theme dictates”), but was also impossible to scale, because it had a bus factor of 1 and a pain level over 9000. I even had it version-controlled in Git all the way back to 2014 (back when I finally joined the Git masochists sect). I was the only person in the world who could maintain it or contribute to it, because, quite frankly, you need to reach geek level 30+ to enter that dungeon, while most people, including new generations, don’t know how to use computers.
I spent time evaluating various alternatives to “coding everything by hand”, including Hugo and Publii (I’ll spare you all the framework-style templating systems turbonerd crap like Bootstrap, Smarty, Django, etc.). Hugo and Publii are very cool conceptually, and would work wonders for a casual geek’s blog, but there are a number of problems they cannot address conceptually, in my view:
- Not advanced and flexible enough for me to do “anything” easily (oh you want to integrate XYZ dynamic features? Yeah, let’s see how well you paint yourself into that corner)
- Relies on their own themes that I can’t be bothered to learn hacking (and I don’t want to be hiring a dev specialized in those technologies to do it for me) just to be able to accomplish my vision (“I want it to look just like that!“). It’s easy to make a nice-looking hello-world website if you fit within the theme’s planned usecases, but as soon as you start saying “I want every core page to have a unique layout depending on the contents” and “I want the front page to look & behave differently from all the rest”, you run into limitations pretty quickly and say “Screw this, if I’m going to start hacking this thing, I’m no better off than writing my own custom website codebase myself.”
- They are arguably designed and best suited for the “one user” usecase. Collaborative editing and permissions management? Not happening.
- Nobody but turbonerds has the skills to understand and manage a static site generator. Most people can’t be bothered to handle files and folders. They live in the browser, and simply giving them a log-in to your site is the only way I can see to lower the barriers to entry among your team.
As much as we geeks love to hate WordPress and the bloat it represents, it is pretty much the standard website building platform that is visibly thriving, and that we know will still be Free & Open-Source and available ten years from now; and for all its warts, with enough experience and geekdom you can tweak and harden it into something fairly reliable and somewhat secure (the fact that automatic updates are now available for both the core and extensions helps; yes, it makes me nervous to think that things may change and possibly break on their own, but you can’t afford to have an un-patched website nowadays, and I think the security benefits of automatic updates outweigh the theoretical compatibility worries).
Combined with the new Gutenberg editing experience, some themes out there are also flexible enough to easily lay out complex pages without feeling like I’m running into limitations all the time.
Not everything is perfect of course. As of 2021, on the performance front, getting consistent and reliable caching working with SuperCache is a mindboggling experience, full of “mandelbugs” (like this one); in my case, each of my websites has at least some (or all) of the caching behavior not working (whether it is some pages never being able to generate cache files, or the cached files not being retained, no matter what you do and what combination of voodoo incantation and settings you use), but maybe someday someone will complete a heavy round of refactoring to improve the situation (maybe you can help there?) and things will Just Work™. But for now, I guess I’ll live with that.
All in all, it is only from 2019 onwards, after much research (and much technological progress in general), that I found myself with enough tooling to make this work in a way that would meet my expectations of design & workflow flexibility, and therefore feel confident enough that this will be my long-term solution for a particular type/segment of my websites. My personal website (of which this blog is only a subset) still is hand-coded, however, because it “does the job.”
Years ago, someone once told me that whenever someone in your team decides to write your company’s website from scratch (or using some templating system), they “inevitably end up reimplementing WordPress… poorly.”
So yeah. We’re using WordPress.
*: idéemarque is the first and only Free & Open-Source branding agency that contributes to the desktop Linux landscape on a daily basis, because that's what I do and I'm already in too deep. Or, as an academic would say, I'm just "unreasonably persistent."
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Comments
2 responses to “CMSes & static site generators: why I (still) chose WordPress for my business websites”
StaSiGs have a point in lower energy consumption, but maybe WordPress is not too bad. So far, I find Pelican flexible enough for my use cases, but they are probably less demanding than yours.
For what it’s worth, WP SuperCache generates static HTML files that completely bypass PHP, so when it works, it works theoretically just as fast as static website generators, and thus, I’m not sure the energy consumption argument would hold water in practice.
That requires the thing to work, though, and the problem I’ve encountered in practice is the cache getting cleared for no good reason (I did try setting really long 45-days expiration delays, enabling or disabling preloading, and even disabling garbage collection entirely… no luck.), or the cache files not getting generated at all for some languages (particularly problematic with multilingual multi-domains websites with HTTPS), etc.
Arguably, in my view, this could/should have been a built-in feature, and in a way, it’s a perfect illustration of Marc Laporte’s “plugin problems” argument. There’s half a dozen caching plugins, and I’ve never found one to work perfectly across my websites.