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.
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.
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.
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.
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.
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
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
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.
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.)
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?)
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.