As a software architect fascinated by design patterns, I’ve been thinking deeply about Commonware’s “anti-framework” philosophy. This isn’t just blockchain-specific - it’s a fundamental tension in software engineering.
The Framework vs Library Debate:
This is decades old:
Frameworks (Rails, Django, Cosmos SDK):
- Inversion of control: Framework calls your code
- Opinionated: One right way to do things
- Batteries included: Everything you need
- Fast to start: Generators, scaffolding
- But: Hard to escape constraints
Libraries (Express, Flask, Commonware):
- You call library code
- Unopinionated: Many ways to compose
- Bring your own batteries: Pick what you need
- Slower to start: More assembly required
- But: Maximum flexibility
The LEGO Block Analogy:
Commonware explicitly uses this:
Frameworks = Pre-built LEGO sets:
- Picture on box shows what to build
- Instructions guide you step-by-step
- Pieces designed for specific model
- Result: Beautiful castle/spaceship/etc
- But: Hard to build something else
Primitives = LEGO blocks:
- No instructions, just blocks
- Standard connections (studs, holes)
- Infinite possibilities
- Result: Whatever you imagine
- But: Need to know what you’re building
Commonware’s Position:
They explicitly call themselves an “anti-framework”:
What they provide:
- commonware-consensus (BFT primitive)
- commonware-cryptography (BLS operations)
- commonware-p2p (networking)
- commonware-runtime (async execution)
- commonware-storage (persistence)
What they DON’T provide:
- Account model (UTXO vs account-based)
- VM (EVM, WASM, or custom)
- Transaction format
- State representation
- RPC interface
You compose these however you want.
Real-World Example:
Building a DEX blockchain:
With Cosmos SDK (Framework):
With Commonware (Primitives):
Tradeoff: 2x time for 10x flexibility
When Frameworks Win:
Use framework when:
Standard use case (yet another app-chain)- Fast time to market (3 months not 6)
- Team not deeply technical (need guidance)
- Want ecosystem (IBC for Cosmos, EVMs for Ethereum)
- Maintenance > innovation (stability matters)
Examples:
- Most DeFi chains (Osmosis, Kava, etc on Cosmos)
- Most rollups (OP Stack, Arbitrum Orbit)
- Most L2s (Polygon CDK)
When Primitives Win:
Use primitives when:
- Novel requirements (doesn’t fit frameworks)
- Performance critical (can optimize everything)
- Long-term project (will grow/evolve)
- Deep expertise (know what you’re doing)
- Flexibility > speed (willing to invest time)
Examples:
- Payments (Tempo - needs <250ms finality)
- Gaming (real-time state transitions)
- High-frequency DeFi (orderbook DEXs)
- Custom consensus (research projects)
The Pendulum Swing:
Software engineering oscillates:
1960s-70s: Assembly (primitives)
1980s-90s: Frameworks emerge (Rails, J2EE)
2000s-10s: Framework dominance
2010s-20s: Microservices, composability
2020s: Back to primitives? (Commonware, etc)
Why the swing back?
- Cloud made infrastructure composable (AWS = primitives)
- Containers made deployment uniform (Docker)
- Rust/Go made systems programming accessible
- Developers more sophisticated (can handle complexity)
The Middle Ground:
What if we had both?
Layered approach:
- Layer 1: Primitives (Commonware)
- Layer 2: Common patterns (reference implementations)
- Layer 3: Full frameworks (opinionated stacks built on primitives)
Example:
- Primitives: consensus + crypto + p2p
- Patterns: UTXO model, account model, EVM integration
- Frameworks: “DeFi stack” or “Gaming stack”
This gives:
- Beginners → Use frameworks
- Intermediate → Use patterns
- Advanced → Use primitives directly
My Questions:
-
Is Commonware too low-level for most developers? Should they provide more “batteries”?
-
Will someone build frameworks ON TOP of Commonware? (Like Rails built on Ruby)
-
Does the primitive approach fragment the ecosystem? (No standard way = less interop)
-
Can documentation/tooling bridge the complexity gap?
My Take:
The anti-framework approach is correct for infrastructure but needs a framework layer on top for adoption.
Compare to AWS:
- EC2/S3 = primitives (flexible, powerful, complex)
- Heroku/Vercel = frameworks (opinionated, easy, constrained)
- Both exist, both have markets
Commonware could be the “AWS of blockchains” - powerful primitives that others build frameworks on.
What do you think? Should Commonware stay pure primitives, or provide more opinions?