It’s been a long, long time coming – years, really – but at long last I have a site I can maybe take enough pride in to use seriously and keep everything together. At least, theoretically; because strictly as I write this the site for it to appear on does not quite yet exist. I have spent weeks on development and testing though, with uncharacteristic productivity, so it should be all ready to go live more-or-less pending only these words.

For a while I’ve wanted to bring my various shenanigans together in a unified site that would present it appropriately, as well as being sufficiently easy to update and maintain that I would actually be inclined to make use of it. The first plan there was to put something together using the Laravel PHP framework; I hacked together a theme derived heavily from Bootstrap, and as a stopgap until a full amazing CMS to suit all my needs could be implemented, I set up some static routes and templates to hold pictures and various javascripty gizmos while keeping the wordy stuff on a Wordpress installation on a different subdomain. From there, I just… well, that was it. Never got around to making the content management WYSIWYG doodads and everything stagnated. This was in effect worse than just writing HTML pages manually, because now adding content also required setting up routes in Laravel, although the notion of having to update navigation menus in a separate file wasn’t too different.

Well, enough was enough. I’d heard of the Pelican static site generator somewhere some time ago and have had it bookmarked to ‘look into’, but somehow in a frenzy of activity I’ve actually gone ahead and put in the work to get everything running, all in a few months at most.

The key point of a static site generator is basically to take care of all the busywork and ideally streamline the process of writing and collecting all the important stuff. With Pelican, I only write these words into a single file, then when it goes to regenerate the site, all the menus, archive pages etc. get updated automatically. That’s not notably any different from a standard blogging platform or CMS, but since it operates mostly on a basis of transforming source files into HTML and just managing metadata around that, it should hopefully afford the flexibility to put pretty much whatever sort of content I want, like arbitrary JavaScript tools and their necessary elements. But there’s also the rationalisation that, by writing everything in text files on my own local system and leaving the web-facing updates to automated tools, maybe there’ll be less ‘friction’ in writing more often? It’s a nice ideal.

There are certainly some drawbacks to static site generation, though. Everything is … static, so comment forms and search bars aren’t exactly features. They are resolvable, generally by loading in and inserting a bunch of stuff through JavaScript (and, in the case of comments, leaving the persistence part to either a third party or something else not-static elsewhere). When this goes live there won’t be comments nor the old posts they appeared on, primarily because I do need to get something live, but the older content should all come in eventually with at least the ‘legacy’ comments rendered statically underneath. At some point I’ll probably (dangerous word) get a useful search running and perhaps the basic social stuff too.

The other obvious problem I see is that, since all the menus and other links on every page are all included statically into every page, that means that simply adding a new page/article means literally every other page/article needs to be regenerated and then uploaded to the server. It should all be fairly lightweight well into the future so it’s not a great concern, but is perhaps something to keep in mind if you’re not locked into static site generation. Worst case, it would be possible to do a static/dynamic sort of blend where the static output includes some constant placeholder that a dynamic layer can then inject navigation into on the server side. That’s how I am (or hope to?) doing the random bit of the header and footer, for which I have far too long a list of random possibilities to abandon to static generation. It could be chosen randomly for each page at generation time but that’s still no fun.

Other than the Pelican stuff, this new iteration is done entirely from the ground up. I like to moan about modern website bloat as much as anyone, clueless as to what 20+MB of JS etc. could even be doing, so in order to not be a total hypocrite I have to abandon the sort of passive indifference that leads to so much junk and dare to give a shit. That means, this time around, no reaching for Bootstrap or prebuilt themes with dozens of helpful libraries and CSS declarations included just in case – I’ve made the whole theme from the ground up. Fortunately with new(ish) CSS tools like flexbox and grid (both used extensively here), it’s not at all hard to put together something that works seamlessly across the whole range of screen sizes. It still takes more effort than having it done for you, of course, but I did have some manner of enjoyment from wrangling declarations to make sure the only time something will overflow and summon a horizontal scrollbar is because of a single word that’s too long. And the results speak for themself – as of publication, the total download for this page is a mere 48 kB, compared to the 391 kB of the prior site made from trimmed and compiled Bootstrap, and the staggering 1.15 MB (!) of the Wordpress page making use of a whole ready-made theme. When you write it all yourself, you just don’t have time to introduce so much gunk 🙂. It also means no third-party dependencies like Google fonts – so instead of presumptiously asserting my favourite typeface onto your undeserving eyes, you can configure your own preference should you have one. And honestly, out of the select few I’ve demoed various stages of development to, literally not one even noticed (or at least commented) that it’s all their browser’s default fonts.

So, what of writing and publishing and streamlining and friction? Well, writing words still takes time, unfortunately. As of writing this exact sentence, there are just a few more than 1111 words, all of which have taken not much longer than an hour to produce. That’s about 17 words per minute, for those keeping up. Admittedly this is all a bit longer than anticipated, but unless I can crack the secret of writing in the darkness of not-quite-yet-sleeping, there’s always going to be that lamentable obstacle. Mostly rambling at this point, but as for how publication goes, that will have to wait until things are live, and well and truly under way with multiple (!) posts. Especially once the verbiage of years past all gets folded in.

I had somewhat intended to provide some examples of the configuration and changes I’d made to get Pelican and docutils working how I wanted, but that might have to wait for another wall of words. If things I think about writing actually get written, then we’ll know the friction is drastically lesser. Or I’ve just been hit with an abrupt notion of duty and dedication.