The Meatspace Blog Manifesto
Conceptually, as a codebase, Lotek was feature complete the day I created it. It could take markdown files and convert them into html, ready to be served. The initial version was less than 200 lines of code.
It’s been six days and now the codebase is just under 2,500 lines total! “That’s nearly a 10x increase in code size,” you exclaim! The reason for this is that I’ve added a lot of features and functionality over the past six days. I’ve:
- Created a command line tool to help manage articles on the site (381 LoC)
- Added more features to the build system like post scheduling (370 LoC)
- Added a huge number of unit tests (1282 LoC!)
- Decoupled the configuration from the code (149 LoC)
Don’t get me wrong, 99 tets on a “tiny blog site manager” is probably
a statement in and of itself. I have no analysis for test coverage. I’m
tired of breaking the render() function.
Really, when you take the tests out of the equation, it’s a little less than 1,250 lines of code, which I maintain is reasonable for a small blog. A clean Wordpress install is about 50 megabytes of stuff. We are not the same.
But do you need all of this optimization? No, but do you need all of the bloat?
And hey, maybe I do need all of this optimization. Let’s line some things up:
- This whole repository (including my dirty build dirs) is only 2 megabytes
- The blog itself (in the
output/dir) is only 68 kilobytes - My current longest single page with no graphics or CSS is only 4.1 kilobytes
- My CSS, probably honestly a little bloated, is 3.9 kilobytes
That means a page (content + CSS) is only ~8 kilobytes and fully functional without CDNs, databases, cookies, advertisers, or any other external dependencies.
So what.
So what?
An interesting thing about engineering is that the stuff we take for granted starts to take on very strange properties the larger or smaller we make it. Miniaturization is an entire study because of this. Often though, software goes the opposite direction. It’s because it’s cheap. Who cares how much bloat and inefficiency is in the stack, because we have lots of CPU and RAM to spare.
And it’s not even always a bad thing. I’d rather my programs use standard libraries than potentially suffer from overly clever attempts to over-optimizing where it is still unnecessary. But let’s see what we can do when we optimize for small.
Some properties of small content that come to mind:
- Small files are easier to serve
- Text compresses well to get even smaller
- They load faster
- They fit into strange places
I want to talk about point number four. It’s interesting and surprising.
When you have very large files, they’re hard to transfer around without a common network, the most common (sadly) of which being the Internet. Your 300kb blog or newsletter is a lot more difficult to send to me when we’re not plugged into the same switch. But when you’re dealing with Small Data(tm), you have new opportunities for transmission. Especially when it’s small data with no external dependencies, like the Internet.
The 6.00 USD Raspberry Pi Pico W, for example, has 2mb of storage and WIFI. You could easily fit a webserver and probably a hundred articles on it (or more). With some extra features like adding a captive portal over an unsecured WIFI Access Point you can make it easy to read. Add some batteries and you could potentially distribute throughout an entire neighborhood for less than 100 USD total.
And none of it touches the internet. Palantir doesn’t know. Google doesn’t know. Even the NSA doesn’t know. Not until they check who in the neighborhood has been buying all of these Raspberry Pis. You’re in the sideband.
Still not impressed? Fine. Let’s go deeper.
If that’s too high-roller for you or requires too much technical acumen, let’s try this: QR Code Blog.
Version 40 of the QR code spec says that it can store between 1,663 - 2,331 data bytes depending on the ECC level. Well compressed, that’s about 4-5kb of data.
That means that, if I cut out most of the CSS, I could post this blog as a sticker on the wall.