The small web is beautiful

An Essay by Ben Hoyt

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.

  1. ​​Why aim small?​​
  2. ​​Features and complexity​​
  3. ​​Solving the problem of software bloat​​
  4. ​​Raw size isn't enough​​
  1. ​​Rediscovering the Small Web​​
  1. Why aim small?

    Why aim small in this era of fast computers with plenty of RAM? A number of reasons, but the ones that are most important to me are:

    • 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.
  2. Features and complexity

    Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called A Plea for Lean Software. 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”.

    1. ​​A Plea for Lean Software​​
    2. ​​Speed is a feature​​
    3. ​​Requirements proliferation​​
  3. Solving the problem of software bloat

    But instead of just complaining, how do we actually solve this problem? Concretely, I think we need to start doing the following:

    • Care about size: this sounds obvious, but things only change when people think they’re important.
    • Measure: both your executable’s size, and your program’s memory usage. You may want to measure over time, and make it a blocking issue if the measurements grow more than x% in a release. Or you could hold a memory-reduction sprint every so often.
    • Language: choose a language that has a chance.
    • Remove: cut down your feature set. Aim for a small number of high-quality features. My car can’t fly or float, and that’s okay – it drives well.
    • Say no to new features: unless they really fit your philosophy, or add more than they cost over the lifetime of your project.
    • Dependencies: understand the size and complexity of each dependency you pull in. Use only built-in libraries if you can.
  4. Raw size isn't enough

    A few months ago there was a sequence of posts to Hacker News about various “clubs” you could post your small website on: the 1MB Club, 512KB Club, 250KB Club, and even the 10KB Club. I think those are a fun indicator of renewed interested in minimalism, but I will say that raw size isn’t enough – a 2KB site with no real content isn’t much good, and a page with 512KB of very slow JavaScript is worse than a snappy site with 4MB of well-chosen images.

    ...[Instead, it's about] an “ethos of small”. It’s caring about the users of your site: that your pages download fast, are easy to read, have interesting content, and don’t load scads of JavaScript for Google or Facebook’s trackers.