4,096 bytes. That is less than this paragraph. Yet Zetsubo by Prismbeings (2018) contains an entire world within that budget: procedural geometry, an atmospheric soundtrack, real-time rendering. No textures. No samples. No assets. Everything generated from mathematics at runtime.
The answer to "how much beauty fits in four kilobytes" turns out to be: rather more than you would believe.
Meanwhile, the median web page in 2025 ships 558 KB of JavaScript, of which 44% never executes. Slack weighs 55 MB for a chat message. A chat message is 100 bytes. The client outweighs its payload by a factor of 550,000. One does not need a degree in engineering to suspect that something has gone rather wrong.
Constraint as Method
The demoscene is not nostalgia. It is a design discipline that has been proving a thesis since the 1980s: constraint does not limit creativity. It clarifies it.
Consider Clean Slate by Conspiracy (2021). Sixty-four kilobytes, the size of a small JPEG. Three people (BoyC, Gargaj, Zoom) fit physically-based rendering, volumetric lighting, procedural textures, procedural geometry, and a fully synthesised soundtrack into that space. It won Revision, the world's largest demoparty. It finished twenty bytes under the limit.
Or consider Prelude to Neobyte by Spectrox (2025): built for TIC-80, a fantasy console with 240 by 136 pixels, 16 colours, and 4 audio channels. Voxel landscapes, copper bar effects, real-time shadows, an underwater endscroller. In 2025, these constraints are entirely artificial. Nobody forces anyone to work with 16 colours. They choose to. And within those constraints, they create something that modern frameworks with unlimited resources rarely achieve: coherence.
That word matters. When you have infinite resources, every decision is hedged. When bytes are limited, every decision is justified. There is no room for "we might need this later" or "it was already in the boilerplate." Every instruction earns its place or it does not ship.
The Cost of Not Caring
One might argue that bytes are cheap now. Storage is cheap. Bandwidth is cheap. And in a narrow, first-world, fibre-connected sense, that is true. But the argument mistakes the invoice for the cost.
A mid-range Android device parses JavaScript twenty-five times slower than a MacBook Pro. Those 558 KB of JavaScript are not merely downloaded; they are parsed, compiled, and executed on a processor with a fraction of the power and a battery the size of a biscuit. React sites spend 431% more main-thread time on mobile than on desktop. "Mobile First" in 2026 means: same application, smaller viewport. Same bundle, same framework, shipped to a device that thermal-throttles under the load.
This is not an engineering trade-off. This is contempt through negligence.
And the dependency graph makes it worse. In 2016, a developer named Azer Koçulu unpublished a package called left-pad: eleven lines of code. Babel broke. React broke. Thousands of projects broke. We called it a fluke. In 2025, Shai-Hulud (a self-replicating worm) compromised 700+ npm packages reaching 132 million monthly downloads. It wiped home directories. We called it an outlier. But 99% of vulnerabilities come from dependencies, not your code. The system is working precisely as designed. We simply chose not to look at the design.
What Constraint Teaches
The demoscene teaches three things that thirty years of enterprise software development has been trying to unlearn:
First: every abstraction has a cost. In a 4 KB intro, there is no room for an abstraction layer that "makes things easier." If the abstraction does not reduce the total size, it is not an abstraction. It is overhead. The same principle holds at any scale. A CSS-in-JS library that adds 13 KB of runtime to avoid writing a class name is not solving a problem. It is importing one.
Second: the best code is the code you did not write. Every line is a liability. Every dependency is an attack surface. Every byte transferred is time your user spends waiting. The question is never "can we add this?" The question is: must we?
Third: reduction is a creative act. Removing code requires deeper understanding than adding it. Anyone can add a feature. Removing one without breaking the system demands that you understand every interaction, every dependency, every assumption. The demoscener who fits a world into 4 KB is not working with less. They understand more.
Proof, Not Theory
This is not an aesthetic preference. It is a falsifiable claim. If constraint-driven engineering works, then small tools should outperform large ones at the tasks they share. They do.
htm/a delivers server-side reactivity in 4.5 KB. React requires 136 KB minified, then adds a virtual DOM that introduces roughly 30% overhead compared to direct DOM manipulation, followed by a hydration step that blocks up to 30% of page load.
minline.js provides DOM-based templating in 1,337 bytes. Not kilobytes. Bytes. The entire library is smaller than most configuration files.
This website, vivianvoss.net, runs on CASTD, a server whose binary is roughly 2 MB. It serves HTML. It handles templates. It manages extensions. It does not require Node.js, npm, a build step, a bundler, or a transpiler. A request arrives. HTML leaves. One job. One process.
Unix understood this in 1973: grep, awk,
sed, sort, uniq:
each does one thing, each takes text in and puts text out, each
composes with any other through a pipe. The industry spent the
better part of a decade building vastly more complex solutions
for what these tools had been doing all along.
The Deeper Question
Every byte that ships without justification is a small act of disrespect: to the user's bandwidth, to their battery, to their time, and to the craft itself. Not because minimalism is fashionable, but because unjustified complexity is a defect. It has failure modes. It has maintenance cost. It has cognitive load. And none of these diminish with time. They compound.
The demoscene proved, four decades ago, that constraint breeds elegance. That technical beauty emerges from reduction. That a world fits in 4 KB if every byte earns its place.
Nothing about that proof has expired.
The question is never whether we can afford to care about every byte. The question is whether we can afford not to.