Goodbye To DIY Site Building

By | 2019-07-13

For the past few years I’ve built off a set of tools I wrote myself, culminating in a system named Parakeet. The idea was to allow really easy page generation (to encourage blogging) and efficient static HTML output. It didn’t work out and I’ve given up on the idea and embraced WordPress.

The way things were

What worked

Parakeet did succeed in terms of producing super efficient HTML, with nice meta elements, (minimal) optimised JavaScript, optimised CSS. As the output was all static pages it meant it could be delivered really easily on even a cheap VM host. The site always scored super-highly on site speed tests.

All source images were optimised, and had sensitive meta-data such as location automatically removed. The JS I used to group images together and resize appropriately on screen worked better than anything I’ve (yet) found in WordPress.

Audio files could be uploaded in WAV and then transcoded to MP3 and OGG to suit all kinds of clients.

What didn’t work

Basically, it was a massive PITA to the point where it was actively putting me off adding any content. Everything could have been fixed, but I no longer have the time or inclination big recreational coding projects.

I had constant problems with the dependency management1 which led to the pages not being updated when they should, or builds failing because a dependency couldn’t be found. The common fix was to drop the dependency database and rebuild which slowed things down.

Similarly, I built in the idea of every resource, even external, being tracked. Part of the dependency management would mean that, occasionally, all external resources would be checked to see if they’re up-to-date. Quite often I’d be trying to make a simple change and it would be blocked because some external site I linked to in a blog post was down and the build stopped.

The Markdown-like syntax I used for posts mostly worked well, but needed more doing to it. There wasn’t a good way to represent embedded video, aside from just pasting in an <iframe>. Because ultimately the page would be fed through an XML parser, I always had to make changs, like expanding fullscreen to fullscreen="fullscreen"

So to WordPress

I’ve already had to get used to WordPress maintenance as I’ve ended up being the WordPress guy for For Folk’s Sake. The site is currently, like the previous version, running on an Amazon Lightsail instance.

I’ve migrated some of the old site content, and may bring some more across over time. Although, frankly, I’m not sure there’s a lot of long-term value in most of it.

  1. If page X is updated, page Y must be as well.