Entropic Thoughts

You Want Technology With Warts

You Want Technology With Warts

I normally skip presentations because I prefer reading, but Building the Hundred-Year Web Service (YouTube) was worth the time.1 Note that despite “htmx” featuring in the title, very little of the presentation is actually about htmx. It is about choosing and using technology in such a way that it won’t require maintenance suddenly due to external factors changing. That’s a drum I’ve been banging for the last few years too, although less visibly.


Petros observes that we know how to build bridges that last hundreds of years: stone, concrete, and steel can all do this with the right engineering. We also know how to build hypertext that is likely to last at least a few decades: use plain html and css. But, Petros asks, how do we create database-y web services that lasts for decades?

Where do we store the data? Where do we perform business logic? He answers thusly:

I won’t debate the specifics here. 2 I’d be tempted to jam Perl into the backend instead of Node.js if I wanted truly low maintenance. I have a feeling a Perl script is more likely to run unmodified 20 years from now than some Node.js thing. But maybe I’m wrong on this. But there were other nuggets in the presentation. For example:

But then the thing that triggered this article: sqlite. One of the more powerful arguments I’ve read against sqlite is that it has a few warts in its defaults, such tables being flexibly typed, foreign keys not being enforced, primary keys being nullable, etc.

I’ve usually thought of these warts as a bad thing. Haskell has them too, like how the built in String type is bad data structure for storing text, and how we’re stuck with a bunch of misnamed functions (mapM, ap, msum, etc.) because we didn’t know better. Oh and the list of Perl’s warts is probably longer than its implementation.

Petros reframes this problem. Every single wart that annoys us today, used to be a reasonable feature that someone relied on in their production code. Every wart we see today is a testament to the care the maintainers put into backward compatibility. If we choose a technology today, we want one that saves us from future maintenance by keeping our wartful code running – even if we don’t yet know it is wartful. The best indicator of this is whether the technology has warts today.

I would much rather, the first time I install an application, “enable foreign keys” – it’s just one line of config – I’d rather do that once, build the thing correctly, and then be confident that if there’s any other built-in behaviour that I didn’t account for, that behaviour isn’t going to change on me and break my application at some point in the future.

Right on.