Posted: February 25, 2020
Anybody who’s been doing IT long enough knows that old ideas – both good and bad – often get dressed up in new frocks and represent themselves as the new hotness.
Thus it is for static site generation. It flopped when we tried it 20 years ago, but I think it’s going to work this time.
Cue hoary story about the old days …
In the first wave of blogging we all (mostly) used the Movable Type blogging package. It was a web-based application that gave you a form in which you entered the text of your blog post. You pressed one button to view an HTML preview of your draft. Once your post looked good, you pressed another button to generate the HTML pages for your site.
That button would regenerate the entire site – every single page!
People hated it.
The problem was that site regeneration was very slow. Once your site reached any significant size it would take many long minutes to add a single article to your blog.
Due to that problem (and licensing concerns with Movable Type) the blogging world moved on from static site generation to live content management systems (CMS). Those are web applications that not only allow you to enter your content, but also render the site pages to visitors upon demand. The most common replacement for Movable Type was WordPress. (I used a different one called Drupal.)
And all was right with the world. Or, it was until we realized how much load the CMS was exerting upon our measly little shared web servers. Even worse, these systems ended up being rife with security problems and subject to very frequent patch updates.
And so people hated that – either they were constantly patching or their site got taken down by a security exploit.
So, years later, the tide has turned again. Static site generation has returned to popular fashion.
And I think it’s a good look. I’m using the Jekyll static site generator for this site.
I think it’s really going to work this time
Here’s why I’m returning to static site generation:
First, no more insecure, overloaded content servers – yay! I render the content on my local machine and push it up to the server. The web server is just serving up static HTML pages.
Second, even if I could manage a single site, managing lots of CMS systems is unscalable. At one time I ran a dozen different sites on my web server, each with its own content system. I rarely kept up to date on security patches for the sites I was responsible for. My guest users tended to be even less diligent. That’s a security (and expense) nightmare waiting to happen.
Thirdly, our machines have gotten more powerful. It currently takes me 1.4 seconds to render this site. As the content grows, it will add a couple seconds, but that’s probably about it. That’s two orders of magnitude better than the old Movable Type site generation.
Finally, the software engineering geek in me is grooving on the idea of implementing a CI/CD pipeline to automate my publishing process.
The challenge of dynamic features
There is one big downside to this approach.
Static publishing doesn’t support dynamic features such as comments or webmentions – or scrobbling “last played song” to my site sidebar.
There are solutions such as embedding Javascript to handle these features. (Again, not an option 20 years ago, but common now.)
My concern with this approach is it violates the web page as content principle, which will make my site hard to archive. I have archival copies of every website I’ve created, thanks to the crawling features of the wget command. Unless somebody wants to build a Javascript interpreter into wget, I’ll lose the ability to easily crawl and archive my site.
I’ve got some ideas – such as injecting dynamic content into the CI/CD pipeline. But I’d hate to require a complete site rebuild every time I scrobble a song.
I’ll continue thinking about this problem. I’m confident there’s a solution out there. And you know I’ll probably blog about it when I figure it out.