Static Considerations

Every now and then I ponder whether or not to move this site to purely static hosting (i.e., off an S3 bucket or an Azure storage account), both because it annoys me somewhat to maintain the VM and because the less code I have running to keep it up the better (and this even after having automated most away all chores and pared the code down to the absolute minimum).

However, I’d miss out on a number of features I’ve grown used to over the years:

• Trivially easy publishing (I can post from anything, anywhere by just placing a file on Dropbox)
• Sane content management (images are filed alongside posts, and my engine automatically references and resizes images as needed without special markup, for both web and RSS views)
• Self-hosted search (not terribly good, but usable)
• Magic redirects to “the page you actually want”, through nearest-neighbor and case-insensitive matches (I believe in useful URL namespaces and actually don’t use search that much–I just have my browser autocomplete the URL and then tweak it to find most of my stuff)
• Arbitrary markup support (many of my decade-old pages rely on Textile markup that simply does not have a Markdown equivalent, and will be much harder to maintain and render properly if I convert them)

Ironically, these same features are what’s holding back development or migration, since:

• Storing content on a filesystem forces me to design around that, which isn’t easy to do in the cloud era, where storage is abstracted away
• Using git webhooks or other typical approaches to (re)building static sites places more dependencies on third-party services
• Static site generators are naturally opinionated about how to deal with images and assume specific content layouts
• Decent indexing services are few, far between and generally pricey (and mine is very closely coupled to SQLite full-text search)
• Most Textile parsers out there (for any language, including Python) are broken due to divergence from the original RedCloth parser, forcing me to keep my own parser around.

Everyone I talked about this raved about Hugo, so I tried it again. It gets many things right (including rendering mangling my 7000-odd pages in a decent amount of time, even if incorrectly), but:

• It lacks built-in Textile support
• Has its own opinionated way to deal with content (which is converging towards how I like to do things, but defaults to the folder-full-of-single-files concept, which does not scale)
• Has trouble dealing with image references (works OK inside a single post, but cannot easily reformat image references to include them in post listings or summaries)
• Generates something like 1GB of tiny files out of my current post tree (which takes a very long time to sync with any kind of cloud storage)

So even though I intend to use it for other things, it’s not the perfect fit. In fact, fiddling with it for a few hours made me wonder if I’ll ever be able to put this site on static hosting without writing my own static site generator–and that way madness lies, because right now I’d very much like to go back to having an actual release cycle for the current version, and constantly find myself lacking the time.

The production version of this site still runs on Hy, a hosted LISP that compiles to Python bytecode, and has served me well for nearly two years.

The codebase is fairly small, absurdly elegant in some places, and carries the least possible amount of legacy warts from its predecessor (which lasted eight years), but for a number of reasons (first and foremost of which is the fact that Hy decided to drop let a few versions ago and broke most of my code) I decided to rebuild it in “pure” Python.

I now have a Python 3.6 version running on my laptop with pretty much everything working save an elusive encoding issue I’ve yet to figure out, and hope to deploy it soon (for an as yet undertermined value of soon).

I toyed around with the notion of porting it to Go or Java (by way of Clojure), but even though it is currently less than 2000 lines of Python, the reliance on some libraries (like lxml, for instance) makes the porting effort unrewarding at best.

I have a private branch of Sushy that spits out HTML to a file tree, and it actually works just fine (except for my magic redirects, obviously).

But I’m somewhat saddened by the fact that the only reason I never really built a site with it is the lack of default document support in Azure Storage.

This UserVoice item has been open since 2014 and it’s been “coming soon” for a while now, but Build 2018 came and went and there was not even a hint of it.

Update: A preview version of the service was actually demoed at Build 2018, but I only noticed it when I scrubbed through a YouTube playlist.

With my luck, it will probably show up tomorrow or next week… Even if it does, however, I am now considering using Azure Functions to do some of the magic bits, the only serious hurdle being that Python 3 support on it is still lagging and that I really don’t want to use NodeJS for this site.

With luck, things will improve soon. Until they do, I’m going to muster some motivation and see if I can move this to the pure Python version over the coming weeks.