the macrobean philosophy

Published 2025-12-05

kill the bloat

"If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'. The current conventional wisdom is so foolish as to book that count on the wrong side of the ledger."

ā€” Edsger W. Dijkstra, "On the cruelty of really teaching computing science"

we were promised simplicity

We were told that software is cheap to copy. That once written, its cost approaches zero. In a literal sense, thatā€™s true. But in practice, itā€™s a profound falsehood.

Ask yourself: what does it take to run a simple web app today?

  1. A specific version of a runtime (Node.js, Python, etc.)
  2. A package manager (npm, pip)
  3. A dozen of third-party libraries
  4. A container and orchestrator tool
  5. Complex CI/CD pipelines

The application itself might be a few hundred lines of code. But its support system, the invisible scaffolding required to keep it standing, is a towering monument to complexity. Every piece of that scaffolding is a potential point of failure, a security risk, and a maintenance burden. Weā€™re not building applications; weā€™re managing supply chains.

Thatā€™s not progress. Itā€™s just bloat. And itā€™s exhausting.

a retreat to sanity

Macrobean is a deliberate retreat. Itā€™s a conscious choice to step off the treadmill of ever-increasing complexity and ask a fundamental question: what if we just built things that work on their own?

This project is an experiment in building a self-sufficient artifact. The goal is to create a single, executable file that contains the entire applicationā€”the server, the runtime, and all the assets. No package managers, no external dependencies. Just one file you can copy, run, and share.

This isn't about rejecting modern tools out of nostalgia. It's a pragmatic decision based on a few core beliefs:

  1. An Application Should Be Whole. The executable you run should be the application, not a pointer to a folder of scripts that, in turn, downloads half the internet. When the application is a single file, deployment becomes copying that file. Rollbacks become replacing it with the previous version. Itā€™s simple, atomic, and predictable.

  2. Every Dependency Has a Cost. A dependency isn't a free shortcut; it's a long-term maintenance contract you didn't explicitly sign. I carefully chose a few stable, battle-hardened libraries (Lua, SQLite, mbedTLS) and baked them in.

  3. Constraints Breed Creativity. The modern developer is a kid in a candy store, paralyzed by choice. By offering a minimal, focused toolset, Macrobean encourages a deeper understanding of the problem at hand. It forces you to think about what you actually need, not what the framework-of-the-week provides.

  4. Software Should Be Built to Last. The churn in the web development world is a feature, not a bugā€”it fuels consulting gigs and conference talks. But it produces software with the shelf life of milk. A self-contained binary, untethered from this ecosystem, is built for a different timescale. It has a chance to be durable, to run ten years from now without a team of engineers to keep it alive.

I'm not the first to feel this way. I am inspired by the radical simplicity of projects like redbean.dev and the user-centric principles of the local-first software movement. Macrobean is an attempt to apply these ideas to create tools that are small, resilient, and respectful of the developer's time and sanity.

This is a bet that in an age of complexity, the most powerful and liberating tool is simplicity itself.

sources of inspiration

The ideas presented here are not formed in a vacuum. I am not the first to talk about this, definately not the last one. My thoughts are heavily influenced by the work and writings of others who have championed simplicity, resilience, and user ownership in software.