Some time ago, I wrote a short article called "Writing HTML in HTML", where I explained why I use plain HTML to write, edit and maintain my web site. As I've been living with my decision to eschew both dynamic content management systems and static site generators for more than a year, I've had the chance to reflect upon it, and I think it is time for me to update and clarify my original vision.

In this post, I want to explore two fundamental principles or criteria that underpinned my original article, but were more or less unpronounced: sustainability and power. I also want to update you on my current site configuration.

Before I begin, I should say that these criteria are my criteria, they're what I value, and don't necessarily line up with what other people value. I think there are others who might value the same things as I do; others will hopefully find the perspective interesting, even if they don't ultimately agree.

First criterion: sustainability

The criterion of sustainability corresponds to the following question:

How difficult will it be for me to maintain – over time –
    a) the entire site, and
    b) any given page on the site?

In my life, this is a rather harsh rule. I know that every extra step I need to perform in order to do something is going to make me avoid doing it more. For this reason, I will consider even minor things – like needing to install a single extra piece of software on my computer, even if it takes only a second to install – to be lowering the sustainability of the web site. Relevant here is not only the effort required for me to edit the site, but also how likely the site is to merely survive over long periods of time, through server migrations and infrastructure changes.

WordPress

As such, I am not talking about "ease of use". WordPress is likely the least difficult way to run a blog, but it is not the most sustainable way, because the effort required to maintain a WordPress site over long periods of time is higher than a folder of static HTML files. To migrate a WordPress site to a new server, you need to export the WordPress database from MySQL on the old server, setup MySQL on the new server and import the old database. This may not be a huge effort, but it is not as simple, neither physically nor mentally, as a copying a folder; thus it lowers the sustainability of the site.

Jekyll

On the other hand, a generated folder of static HTML files is not sustainable just because it can easily be copied to a new server without having to worry about "invisible" databases. While it is easy to migrate the site to a new server, it is not effortless to update the contents of the site, because you can't re-generate a Jekyll-driven site if you don't have Jekyll installed on the computer. Furthermore, it is not uncommon for there to be differences in behavior between different versions of the same generator, making it difficult to maintain the site over long periods of time; if new versions of your static site generator introduce breaking changes, your site is not sustainable, because you will have to update its code whenever you update the generator.

HTTPS

Sustainability is also the one of the many reasons why my web site is served over HTTP and not HTTPS. The problem with HTTPS is that you need to get a certificate from a trusted authority, which either costs money or is free but needs to be updated every month, and even if you pay for it, you need to renew the certificate every year or so. If the operation of your blog depends on a monthly certificate renewal from Let's Encrypt – even if the renewal is set up to be automatic – it is less sustainable than serving your site over HTTP. HTTP will always be around, will always be supported and will never require a certificate.

Another problem with HTTPS is that it is very difficult to revert back to HTTP once you have started using HTTPS. Every outside link to your web site will be incorrect, and you can't redirect HTTPS traffic to HTTP without a valid certificate. In other words, once you start using HTTPS, you will be forever dependent on the certificate renewal process.

The more a web site resembles a folder of ungenerated, static HTML files, served over HTTP, the more sustainable it is. As long as the web exists, there will be web servers capable of serving static HTML files without requiring any extra setup; static HTML is foolproof. With that said, there are other things you can generally count on being available without extra setup. One such thing is PHP. A folder of mostly static HTML pages, enhanced by PHP includes, is nearly as sustainable as a folder of completely static HTML pages.

Second criterion: power

The second criterion, power, corresponds to the following question:

How limited am I in my creation and maintenance of
    a) the structure of the entire site, and
    b) any given page on the site?

This is also a rather important rule in my life, at least as far as technology is concerned. I like doing things the way I like doing them, especially when it comes to a creative endeavor – which building a web site is. I don't like to be hindered by the software I use, unless the software is good enough to outweigh the irratation provoked by its limitations.

Streamlining

To be fair, to make the creation and maintenance of a site easier and more powerful in some regards, it seems necessary to introduce limitations in other regards. For example, if I want an identical navigation menu on every page, it is wise to use a PHP include or some type of templating engine; but this, in turn, limits my power to customize the navigation menu of each page specifically according to that page's needs. In streamlining the site's navigation menu, some freedom is lost.

This type of streamlining is not a bad idea. The problem with most content management systems and static site generators is that they streamline too much. If I implement a common navigation menu by putting a PHP include on every page that needs it, then I can choose not to include it on any given page. But if I implement the navigation menu by enforcing a single common template for all pages – which is what most CMSs and SSGs do – then I can not nearly as easily choose not to include the navigation menu on some of the pages. If I need to do so, it is possible, but I am forced to work around the system.

Structure

Likewise, static site generators like Jekyll usually make it very hard to freely choose a directory structure for your site. They are almost always built for very simple purposes: all blog posts go in _posts, and more complex directory structures are usually very difficult to implement, if not impossible. CMSs are generally more flexible, but they too can be difficult to bend to your specific needs. Ultimately, in terms of flexibility, a folder of static, ungenerated HTML beats everything else, especially when combined with an .htaccess file.

Markup language

CMSs and SSGs share the tendency to avoid plain HTML: most CMSs use a WYSIWYG editor, while SSGs usually use Markdown. This is an obvious and severe limitation: many things in this very article – such as the red text or the right-aligned headings – are impossible to write in Markdown (without reverting to actual HTML inside the Markdown document). But as I mentioned in my original post, there are actually HTML editors that don't suck, even WYSIWYG editors. I am using KompoZer, one such editor, to write this very post.

If you use a CMS or SSG, you constantly have to battle its limitations. You should consider whether its benefits are great enough to justify this struggle. They might be – but I suspect that, for many technologically talented people, they are not.

My current solution

Perhaps my own web site (the one you're visiting right now) can serve as inspiration as to how to build a web site according to these criteria. It is currently implemented in the following way:

• The site is a folder of mostly static HTML files, enhanced by zero, one or two PHP includes, depending on the page:

• Navigation menu
• Comments section

The comments system, written in PHP, works by appending new comments to an HTML file located in the same directory as the page being commented on. This HTML file is included via PHP on the page. This system is not nearly as efficient as a database-driven one, but it is drastically more sustainable. (You can try out the system below.)


• I have an RSS feed implemented as a PHP script, which pulls the posts to include in the feed from the site's front page and subsequently extracts the contents of each post from their respective file. The front page is updated manually.
  

• All files upon which the various pages on the site depend – the stylesheet, the navigation menu script and the comments script – are put in a folder at the site's root named 1. If I ever choose to re-write the site, I can keep this 1 folder, so that the old pages still work, and put the new files, like the stylesheets and scripts for the new pages, into another folder named 2 – and so on forever.

In my initial article, I put forward the idea of putting all files upon which a page depends in that page's directory. Pages would then be self-contained. I ultimately decided against this, because a) it is useful for some pages to share some common files, such as a stylesheet, and b) if the stylesheet always resides at the same URL, browsers will save it in the cache.

As you can see, I have introduced some dynamism to the site, most notably the comments system. (It has bothered me that very few blogs support comments nowadays. How am I supposed to respond to a blog post? E-mail the author? What usually happens is that the discussion takes place elsewhere – on Reddit, Lobsters, Hacker News etc. – and not on the blog post itself. Is this good?)

Conclusion: Static HTML is still king, but it benefits greatly from a little dynamism, written in PHP, to provide useful things, such an RSS feed or a comments system.