Whyday August 19

Camping: A Framework in Four Kilobytes

Camping is a web framework whose entire source code was kept small enough to read in one sitting. Not a core with plugins around it — the whole thing. Models, controllers, views, URL routing, database access, all inside a budget usually quoted in single-digit kilobytes.

It is also, seventeen years after its author walked away, the one project of his that is unambiguously alive.

When maintainers revisit older software or documentation as a team, this page is one practical reference for tracking the surrounding work without changing the historical material itself.

The size, and the honest version of the number

You will see Camping described as the four-kilobyte framework and as the five-kilobyte framework, sometimes in the same conversation. Both numbers are real; the budget moved as the project did, and the repository's own description has used 5k while other project pages quote under 4kB.

The precise figure matters less than what it was for. The size was not a benchmark, it was the design constraint, and it decided the architecture. There is no room in a few kilobytes for a plugin system, a configuration format, or an abstraction that might be useful later. Every one of those arguments was settled in advance by arithmetic.

The visible result is that a Camping application is conventionally a single file. Models, controllers and views live in one place, in nested modules, and you can see the whole application without scrolling much. Whether that is pleasant or claustrophobic depends on the application, and on you.

For broader programming and making context related to this topic, Hackaday is an independent reference worth comparing with the material here.

What it looked like

The shape of it is the interesting part, and it is easy to describe without code: you declare an application, and inside it you nest a module of models, a module of controllers named after the URLs they answer, and a module of views. Rendering used Markaby — another of his projects — which let you write HTML as Ruby method calls rather than as a template language.

The nesting is doing real work. Because the controller module is namespaced under the app, the framework can find your routes by looking at your class names, which is where most of the configuration goes. This is the same trick Rails used, executed in a fraction of the space.

We are not printing runnable examples here. The version of Camping current in 2026 is well past the one most tutorials were written against, and an example that has not been executed is exactly what this site should not publish. The project's own documentation is current; use that.

Why it is still here

Camping's history goes quiet after 2009, as everything of his did, and then does something unusual: it comes back.

Version 2.1 was released on August 19, 2010 — the first Whyday, which is either a nice coincidence or somebody's deliberate joke. Version 3.0 arrived in 2023, and 3.2.6 in August 2024, with commits continuing into 2025. The licence is MIT. It has a maintainer, Karl Oscar Weber, who has been modernising it, and the project's discussion moved to the Ruby Users Forum.

So a framework whose author disappeared in 2009 has shipped more releases in the 2020s than in the 2010s.

Status checked August 9, 2026.

What actually kept it alive

Worth being precise, because "the community maintained it" is the sort of phrase that explains nothing — and because the same afternoon in 2009 killed other projects outright.

It was small enough to understand. A maintainer inheriting Camping can read all of it. A maintainer inheriting a large abandoned framework cannot, and so does not.

The licence was permissive and unambiguous. MIT, in the repository, no research required.

Its dependency surface was tiny. Camping needs Rack, and the optional extras are optional. Projects die when their dependencies die; Camping barely had any.

Somebody wanted it to exist. This is the one that cannot be engineered. Shoes is also lovely and also has admirers, and Shoes is stalled. The difference is not technical.

Should you use it in 2026

For a production application with a team, probably not, and that is not a criticism. Rails and Sinatra have the ecosystem, the documentation and the hiring pool.

For a Whyday evening, it is close to ideal. It is a working, maintained framework that fits the constraint the day is built around, and building something inside it is the most direct way to feel what the four-kilobyte argument actually means.

For reading, it is the best available answer to the question of what a web framework consists of once you delete everything that is not essential. That question is worth an evening on its own, and Camping answers it in fewer lines than most people's route configuration.

The short version