not doing
permacomputing principle #4
the most sustainable computation is the one that does not happen. the most efficient byte is the one never sent. the greenest server is the one never powered on. not doing is not failure. it is the first design decision.
permacomputing names seven principles for computing within planetary limits. the fourth is the most uncomfortable: not doing. it asks whether the thing you are about to build should exist at all.
the web industry does not ask this question. it ships first, measures later, optimizes never. the average page loads 2.5MB to deliver 12KB of text. the remaining 2,488KB is machinery: frameworks, analytics, fonts, modals, cookie banners, scroll-triggered animations, A/B test harnesses, and JavaScript that exists to manage other JavaScript.
not doing means refusing that machinery before it starts.
what this page does not do
nine things this page chose not to do. each absence is a decision. each decision saved bytes, watts, seconds, and trust.
the cost of doing
the seven principles
- 1. scale down — use less computation, less storage, less bandwidth
- 2. maximize lifespan — build for durability, not planned obsolescence
- 3. keep it small — small programs are understandable, auditable, repairable
- 4. not doing — the most radical: question whether to build at all
- 5. use what exists — reuse before creating. adapt before replacing
- 6. challenge the obvious — reject defaults that waste resources
- 7. practice solidarity — share knowledge, tools, and restraint
principle 4 is the hinge. principles 1-3 assume you are building something and ask you to build less of it. principle 4 asks whether you should build it. principles 5-7 assume you decided yes and ask you to build it responsibly.
most sustainability discourse lives in 1-3 and 5-7. compressing images. choosing green hosting. using system fonts. those are necessary. they are not sufficient. if the page should not exist, optimizing it is a performance of concern.
applying not doing
- does this modal need to exist, or could the information be on the page?
- does this carousel need to exist, or could you show the best image?
- does this notification need to exist, or could the user check when ready?
- does this SPA routing need to exist, or could these be separate pages?
- does this loading spinner need to exist, or could the data arrive first?
- does this analytics script need to exist, or could you just ask users?
- does this cookie banner need to exist, or could you not track anyone?
- does this framework need to exist, or could you write HTML?
every "does this need to exist" that resolves to "no" removes code, dependencies, requests, watts, and failure modes. it is the only optimization with zero tradeoffs.
the paradox
this page exists to argue that things should not exist. the contradiction is noted. the page justifies itself only if it prevents more bytes than it costs. one developer reconsidering one modal saves more than this page weighs.
the best feature is the one you delete.
the best page is the one you don't build.
the best byte is the one you don't send.
not doing is the hardest design discipline because
it produces nothing to show in a portfolio review.
that is why it matters.
— void