barnsworthburning.net
- What this site is
- Colophon
- Contact me
- Shortlist of interesting spaces
- Behind the scenes
m o t i o n l e s s
m o t i o n l s e s
m o t i o n s l e s
m o t i o s n l e s
m o t i s o n l e s
m o t s i o n l e s
m o s t i o n l e s
m s o t i o n l e s
s m o t i o n l e s
s o m t i o n l e s
s o m t i n o l e s
s o m t n i o l e s
s o m n t i o l e s
s o m n t o i l e s
s o m n o t i l e s
s o m n o t l i e s
s o m n o l t i e s
s o m n o l i t e s
Collections of articles, links, and other material from around the web, relevant to software design and engineering.
I've been tracking my listening habits with last.fm since I was in high school. As I'm about to turn 30, it's nice to be able to look back on almost my entire adult life – to see how I've changed and how my tastes have changed with me.
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.
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.
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”.
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.
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.