Frameworks vs Primitives: Is Commonware's 'Anti-Framework' Approach the Right Call?

General
1

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:

  • :white_check_mark: Standard use case (yet another app-chain)
  • :white_check_mark: Fast time to market (3 months not 6)
  • :white_check_mark: Team not deeply technical (need guidance)
  • :white_check_mark: Want ecosystem (IBC for Cosmos, EVMs for Ethereum)
  • :white_check_mark: 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:

  • :white_check_mark: Novel requirements (doesn’t fit frameworks)
  • :white_check_mark: Performance critical (can optimize everything)
  • :white_check_mark: Long-term project (will grow/evolve)
  • :white_check_mark: Deep expertise (know what you’re doing)
  • :white_check_mark: 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:

  1. Is Commonware too low-level for most developers? Should they provide more “batteries”?

  2. Will someone build frameworks ON TOP of Commonware? (Like Rails built on Ruby)

  3. Does the primitive approach fragment the ecosystem? (No standard way = less interop)

  4. 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?

2

Victor, excellent framing! As a Cosmos SDK developer for 3 years, let me add the framework perspective - what we gain and lose with opinionation.

Cosmos SDK: The Framework Experience:

What Cosmos SDK Provides:

Consensus: Tendermint (integrated, 6s finality)
Networking: P2P (built-in)
State: IAVL tree (Merkle proofs included)
Modules: Bank, staking, gov, IBC (composable)
CLI: Automatic command generation
APIs: REST, gRPC, WebSocket (auto-generated)

Developer Experience:

To build a blockchain:

ignite scaffold chain mychain
ignite scaffold module mymodule
ignite scaffold message createOrder
# 15 minutes, running blockchain

Result: Full blockchain with staking, governance, IBC-ready.

The Learning Curve:

Month 1: Following tutorials, everything works
Month 2: Customizing modules, still good
Month 3: Need to modify consensus → Wall hit

The wall: Tendermint + ABCI are deeply integrated. Want 2s finality instead of 6s? Good luck.

What I Love About Cosmos SDK:

  1. IBC Native: Connect to 50+ chains immediately
  2. Proven: Billions in TVL, battle-tested
  3. Ecosystem: Tooling, libraries, community
  4. Documentation: Excellent tutorials
  5. Hiring: Easy to find Cosmos developers

What Frustrates Me:

  1. Performance Ceiling: Cannot break 6s finality easily
  2. Go Required: No Rust option (until recently)
  3. Framework Lock-In: Hard to swap components
  4. ABCI Overhead: Abstraction adds latency
  5. State Model: IAVL is slow for some use cases

When I would Consider Commonware:

Scenario 1: Performance-Critical

If I needed <1s finality, Cosmos SDK cannot do it. Would need to:

  • Fork Tendermint (massive work)
  • Or switch to Commonware (rebuild from scratch)

Tradeoff: Months of work vs guaranteed performance

Scenario 2: Custom Consensus

If I needed research consensus (not Tendermint):

  • Cosmos: Replace consensus layer (breaks everything)
  • Commonware: Swap consensus primitive (supported)

Scenario 3: Rust Requirement

If team is Rust-first:

  • Cosmos: Use Cosmwasm (smart contracts, not full chain)
  • Or wait for Cosmos SDK Rust port
  • Or use Commonware (native Rust)

Comparison:

Aspect Cosmos SDK Commonware
Time to MVP 1 month 4-6 months
Customization Low High
Performance 6s finality <1s possible
Ecosystem Large Small
Hiring Easy Hard
Long-term Good Excellent

My Honest Take:

For 90% of chains, Cosmos SDK is better choice:

  • Faster development
  • More tooling
  • IBC connectivity
  • Proven at scale

For 10% of chains (performance-critical, novel designs), Commonware makes sense:

  • Payment systems (<250ms needed)
  • Gaming chains (<100ms latency)
  • Research projects (custom consensus)
  • High-performance DeFi (orderbooks)

The Framework Layer Question:

Victor asked: Will someone build frameworks on Commonware?

I think yes, and here is what it might look like:

Commonware DeFi Stack:

  • Primitives: Commonware (consensus, crypto, p2p)
  • Patterns: Account model, EVM, DEX modules
  • Tooling: CLI generators, deployment tools

This would give:

  • Performance (Commonware base)
  • Ease (framework scaffolding)
  • Flexibility (can drop to primitives if needed)

Analogy: React (library) + Next.js (framework)

Commonware = React (primitives)
Future stack = Next.js (opinionated framework)

What Cosmos Could Learn:

Cosmos SDK is rebuilding for modularity:

  • Cosmos SDK v2: More modular
  • CometBFT: Consensus separated
  • Rust SDK: Coming

Trend: Everyone moving toward composable primitives.

My Recommendation:

New projects: Start with Cosmos SDK, prototype fast
Performance blocked: Migrate to Commonware
Research/novel: Start with Commonware

Bottom line: Frameworks win for most. Primitives win for edge cases. Both have place.

3

Great discussion! As a Polkadot/Substrate builder, let me add another framework perspective with different design philosophy.

Substrate: The Modular Framework:

Substrate tries to be middle ground between monolithic framework and pure primitives.

Substrate Architecture:

Core (Opinionated):

  • Consensus: GRANDPA + BABE (or Aura)
  • Runtime: WASM execution
  • P2P: libp2p networking
  • Database: RocksDB/ParityDB

Pallets (Composable Modules):

  • frame_system (required)
  • pallet_balances, pallet_staking, etc (optional)
  • Custom pallets (your logic)

Philosophy: “Modular framework” not “pure primitives”

Comparison to Commonware:

Aspect Substrate Commonware
Philosophy Modular framework Pure primitives
Consensus GRANDPA/BABE/Aura Simplex (swappable)
Runtime WASM (mandated) Any (bring your own)
Language Rust Rust
Modules Pallets (pre-built) None (build yourself)

Key Difference:

Substrate: “Here are modules, compose them”
Commonware: “Here are primitives, build modules”

Substrate Advantages:

1. Polkadot Ecosystem:

  • Deploy as parachain
  • Shared security
  • Cross-chain messaging (XCM)

2. Battle-Tested Modules:

  • 100+ pallets available
  • Staking, governance, identity, etc
  • Production-ready

3. Tooling:

  • Substrate node template
  • Front-end templates
  • Block explorers

4. WASM Runtime:

  • Forkless upgrades
  • Runtime in state
  • Can upgrade without hard fork

Substrate Limitations:

1. Complexity:

  • FRAME macros (steep learning curve)
  • Pallet interactions (subtle bugs)
  • Weight system (gas metering complexity)

2. Opinionated:

  • Must use WASM runtime
  • Must use pallets structure
  • Hard to use non-Rust VMs

3. Polkadot Lock-In:

  • Most value is parachain access
  • Without Polkadot, less compelling
  • Relay chain dependencies

When to Use Substrate:

:white_check_mark: Want Polkadot ecosystem
:white_check_mark: Need forkless upgrades (WASM runtime)
:white_check_mark: Standard blockchain (pallets fit your needs)
:white_check_mark: Rust team

:cross_mark: Need custom consensus (GRANDPA/BABE fixed)
:cross_mark: Do not want Polkadot dependency
:cross_mark: Need <1s finality (GRANDPA is 12s+)

When to Use Commonware:

:white_check_mark: Performance critical (<1s finality)
:white_check_mark: Novel consensus (research)
:white_check_mark: No framework lock-in wanted
:white_check_mark: Custom everything

:cross_mark: Want fast development (frameworks faster)
:cross_mark: Need battle-tested modules
:cross_mark: Want ecosystem (Polkadot/Cosmos/Ethereum)

The Spectrum:

Most Opinionated → Least Opinionated:

OP Stack (rollup framework) →
Cosmos SDK (app-chain framework) →
Substrate (modular framework) →
Commonware (pure primitives) →
Writing from scratch

Each has use case.

My Experience:

Built 2 parachains with Substrate. Would I use Commonware instead?

For those projects: No

  • Needed Polkadot security/ecosystem
  • Standard DeFi use cases
  • Pallets worked well

For hypothetical fast-finality project: Yes

  • GRANDPA too slow (12s+ finality)
  • Would need custom consensus
  • Substrate cannot easily swap consensus

The Future:

I think we will see:

2025: Frameworks dominant (Cosmos, Substrate, OP Stack)
2026-27: Primitive layers emerge (Commonware, similar)
2028-30: Frameworks built on primitive layers

Similar to:

  • AWS (primitives) → Platform.sh/Heroku (frameworks)
  • React (library) → Next.js/Gatsby (frameworks)
  • Express (minimal) → Nest.js (opinionated)

Both layers valuable.

My Take:

Substrate = Good for most projects (90%)
Commonware = Good for performance/research (10%)

But that 10% includes highest-value use cases (payments, gaming, HFT).

Question for community:

Is there room for 5+ blockchain frameworks/primitives? Or will market consolidate to 2-3 winners?

4

As an independent blockchain developer who has tried multiple approaches, let me add the practical solo developer perspective.

My Journey:

Project 1 (2022): Built with Cosmos SDK

  • Time: 6 weeks to MVP
  • Result: Functional blockchain with staking
  • Problem: Needed custom state model, could not modify easily
  • Outcome: Shipped but compromised on features

Project 2 (2023): Built with Substrate

  • Time: 8 weeks to MVP
  • Result: Functional parachain
  • Problem: FRAME macros confusing, hard to debug
  • Outcome: Shipped but frustrated with complexity

Project 3 (2024): Built from scratch (C++)

  • Time: 6 months, still not done
  • Result: Custom everything
  • Problem: Reinventing wheels, security concerns
  • Outcome: Abandoned, too much work

Project 4 (2025): Evaluating Commonware

  • Time: TBD (in research phase)
  • Goal: High-performance orderbook DEX
  • Requirement: <500ms finality

What I Need as Solo Developer:

Must Have:

  • :white_check_mark: Clear documentation (learn quickly)
  • :white_check_mark: Example code (copy-paste-modify)
  • :white_check_mark: Active community (get help when stuck)
  • :white_check_mark: Good error messages (debug easily)

Nice to Have:

  • :star: CLI tools (automate boring stuff)
  • :star: Testing framework (catch bugs)
  • :star: Monitoring (know what is happening)
  • :star: Deployment guides (ship without ops team)

Framework vs Primitive Reality:

Cosmos SDK:

  • :white_check_mark: Excellent docs
  • :white_check_mark: Many examples
  • :white_check_mark: Large community
  • :white_check_mark: Good errors
  • Solo friendly: Yes

Substrate:

  • :warning: Complex docs (FRAME confusing)
  • :white_check_mark: Some examples
  • :star: Good community
  • :cross_mark: Cryptic macro errors
  • Solo friendly: Medium

Commonware:

  • :warning: Early docs (improving)
  • :warning: Few examples (Alto only)
  • :warning: Small community
  • :red_question_mark: Unknown (Rust errors)
  • Solo friendly: Unknown

The Assembly Tax:

Primitives require more assembly. As solo developer:

With Framework:

  • Consensus: Built-in
  • Networking: Built-in
  • CLI: Generated
  • RPC: Generated
  • Monitoring: Included

With Primitives:

  • Consensus: Configure (1-2 days)
  • Networking: Configure (1-2 days)
  • CLI: Build yourself (3-5 days)
  • RPC: Build yourself (3-5 days)
  • Monitoring: Build yourself (2-3 days)

Extra: 2-3 weeks work

For solo dev, 2-3 weeks = significant.

When I would Choose Primitives (Commonware):

Only if:

  1. Framework genuinely cannot do it (performance/customization)
  2. Project is long-term (3-5 years, worth investment)
  3. I deeply understand blockchain internals
  4. Community support available

For Project 4 (DEX), evaluation:

Requirements:

  • <500ms finality (cannot use Cosmos 6s or Substrate 12s)
  • Custom orderbook matching (standard frameworks not optimized)
  • High throughput (10k orders/sec)

Cosmos SDK: Cannot meet finality requirement
Substrate: Cannot meet finality requirement
From scratch: Too much work
Commonware: Possible, but risky (solo + new tech)

My Decision Process:

Option A: Compromise with framework

  • Use Cosmos SDK
  • Accept 6s finality
  • Ship in 2 months
  • May not be competitive

Option B: Bet on Commonware

  • Use primitives
  • Get <500ms finality
  • Ship in 5-6 months
  • Risk: What if I get stuck?

Risk Mitigation:

If I choose Commonware:

  1. Build prototype first (2 weeks, validate approach)
  2. Join community early (Discord, ask questions)
  3. Contribute back (document learnings)
  4. Budget extra time (6 months → plan for 9)

What Would Help:

For Commonware to be solo-friendly:

  1. Starter templates:

    • Simple blockchain template
    • DEX template
    • Payment chain template

  2. Cookbook:

    • “How to add RPC endpoints”
    • “How to implement custom transactions”
    • “How to deploy validators”

  3. Debugging guides:

    • “Common errors and solutions”
    • “How to trace consensus issues”
    • “Performance profiling guide”

  4. Migration guides:

    • “Coming from Cosmos SDK”
    • “Coming from Substrate”
    • “When to use each primitive”

Compare to Rust ecosystem:

Rust = Difficult language
But: Amazing docs, helpful compiler, great community
Result: Accessible despite difficulty

Commonware could follow this model.

My Honest Recommendation:

For solo developers:

Use framework (90% of cases):

  • Time is your scarcest resource
  • Community support matters
  • Faster validation of ideas

Use primitives (10% of cases):

  • Framework genuinely blocks you
  • Long-term project (years not months)
  • You are expert-level developer
  • Novel requirements

For me specifically:

Probably starting with Commonware prototype, fallback to Cosmos SDK if stuck.

High risk, high reward. But solo dev life is about learning, so worth trying.

Questions for Commonware team:

  1. Are you building starter templates?
  2. What is the learning path for new users?
  3. Is there mentorship/support for early adopters?
  4. What percentage of users do you expect to be solo devs vs teams?

Anyone else solo building with primitives? How is it going?