|
|
|
|
Summary: I believe that small websites are compelling aesthetically, but are also important to help us resist selling our souls to large tech companies. In this essay I present a vision for the “small web” as well as the small software and architectures that power it. Also, a bonus rant about microservices. About fifteen years ago, I read E. F. Schumacher’s Small is Beautiful and, despite not being interested in economics, I was moved by its message. Perhaps even more, I loved the terse poetry of the book’s title - it resonated with my frugal upbringing and my own aesthetic. I think it’s time for a version of that book about technology, with a chapter on web development: The Small Web is Beautiful: A Study of Web Development as if People Mattered. Until someone writes that, this essay will have to do. There are two aspects of this: first, small teams and companies.
I’m not going to talk much about that here, but Basecamp and many others have. What I’m going to focus on in this essay is small websites and architectures. I’m not the first to talk about the “small web”, but, somewhat surprisingly, only a few people have discussed it using that term. Rediscovering the Small Web by Parimal Satyal: a fabulous article about the joy of small, independent (and sometimes retro) websites in contrast to the “commercial web”. What is the Small Web? Aral Balkan of the Small Technology Foundation: more of a manifesto against the surveillance of Big Tech than something concrete, but still interesting. Why aim small in this era of fast computers with plenty of RAM? Fewer moving parts. It’s easier to create more robust systems and to fix things when they do go wrong. Small software is faster. Fewer bits to download and clog your computer’s memory.
Reduced power consumption. This is important on a “save the planet” scale, but also on the very local scale of increasing the battery life of your phone and laptop. The light, frugal aesthetic. That’s personal, I know, but as you’ll see, I’m not alone. So let’s dive in. I want to cover a bunch of different angles, each with its own subheading. If we’re going to talk about a small web, we need to start with small software. As a teen, I learned to program using x86 assembly and Forth - perhaps odd choices, but my dad was heavily into Forth, and I loved how the language was so simple I could write my own bootstrapped compiler. In terms of career, I started as an embedded programmer - not as in “embedded Linux” but as in microcontrollers where 16KB of RAM was generous. My current laptop has 16GB of RAM, and that’s not a lot by today’s standards.
We were building IP-networked products with one millionth the amount of RAM. Those kinds of micros are as cheap as chips (ahem), and still widely used for small electronic devices, sensors, internet-of-things products, and so on. You have to think about every byte, compile with size optimizations enabled, and reuse buffers. It’s a very different thing from modern web development, where a JavaScript app compiles “down” to a 1MB bundle, or a single Python object header is 16 bytes before you’ve even got any data, or a Go hello-world binary is 2MB even before you’ve added any real code. How do you create small programs? I think the main thing is that you have to care about size, and most of us don’t think we have time for that. Apart from embedded development, there’s an entire programming subculture called the demoscene that cares about this. They have competitions for the smallest 4KB demos: who can pack the most graphical punch into 4096 bytes of executable.
That’s smaller than many favicons! Many demosceners go on to become game developers. It’s not just about executable size … ’re developing your next command line tool, if you use Go or Rust or even C, your program will be much faster, smaller, and use less memory than a Python or Java equivalent. And easier to install. If you don’t understand why, please do learn. But why not apply some of the same principles to web development? In the web world, I think the main trick is to be careful what dependencies you include, and also what dependencies they pull in. More about this below. His take is that “a primary cause for the complexity is that software vendors uncritically adopt almost any feature that users want”, and “when a system’s power is measured by the number of its features, quantity becomes more important than quality”. He goes on to describe Oberon, a computer language (which reminds me of Go in several ways) and an operating system that he believes helps solve the complexity problem.
|
|
