The Anti-Bloat Manifesto
Software size has a cost. Applications often ship code, runtimes, and assets they never use.
A small service, a large artifact
A small service built with a modern framework can ship an artifact far larger than the application itself, and reserve substantial memory before serving a request.
The artifact may include a user environment, a language runtime, a framework, a package graph, and build residue. Much of it supports general cases the application does not use. It is shipped anyway unless the build removes it.
The industry does not consider this remarkable. We do.
Where the weight comes from
Interpreted and just-in-time compiled languages carry a general execution engine into production, whether the application uses all of it or not. Each package may bring more packages, along with metadata and assets the application never executes. An application calls a framework, which calls data and network layers, each with its own structures and logging.
These compound. A broad runtime carries a broad dependency graph through general-purpose machinery. The result can be much larger than the operation it performs.
The costs show up in operation. More memory per process means larger machines. More code to load slows startup. Unused code can still be reachable, and still has to be inventoried. Large artifacts take longer to store, transfer, scan, and install. Storage may be cheap per unit. Waste still multiplies.
What we ship
We compile applications into self-contained native artifacts. The deployed product does not need a language interpreter or an application package directory beside it. The compiler includes reachable code and leaves unused library modules out.
Size is not the only goal. We trade the convenience of a general runtime and package ecosystem for work we have to perform and maintain ourselves. We make that trade when the result is easier to ship, operate, and understand.
The same problem reaches the browser. Pages carry scripts, trackers, frameworks, and client-side package trees that every visitor must download and execute. As “Size does matter, actually” argues, content became richer while the machinery around it grew faster still. A page built mainly to present text and links should not require an application runtime to become readable.
Developer productivity matters more than winning a binary-size contest. Containers, runtimes, and frameworks can justify their cost. Size is still a design constraint, paid by the people who run or download the product.
Ship the product, not every tool used to build it.