The short version

Plumego is not trying to “beat” Framework X.

Plumego is trying to keep one promise:

Make Go services predictable, auditable, and easy to evolve over years—by staying close to the standard library and avoiding hidden behavior.

Framework X may be a better fit when you want maximum convenience and ecosystem integration out of the box. Plumego is a better fit when you want a small, explicit, long-lived foundation.

What people usually mean by “Framework X”

When someone says “Why not Framework X?”, they typically want one (or more) of these:

• Faster initial development (less boilerplate)
• A large plugin ecosystem (auth, validation, swagger, ORM integrations)
• Strong conventions (a “right way” to structure the app)
• Built-in features (DI, config, i18n, background jobs, etc.)
• A popular default choice (easier hiring, more tutorials)

These are valid goals. Plumego simply optimizes differently.

Plumego’s design stance

1) Standard library alignment (not abstraction-first)

Plumego treats net/http as the base model, not something to hide.

• You should be able to reason about request flow as if it were native http.Handler.
• You should be able to replace parts without rewriting your app.
• You should be able to debug production issues with minimal mental translation.

This tends to make Plumego feel “smaller” than Framework X—but also less surprising over time.

2) Explicit composition over implicit convention

Many frameworks provide “magic defaults” that are convenient early, then hard to audit later:

• implicit middleware ordering
• implicit request context injection
• hidden global state / registries
• reflection-driven behavior that’s hard to grep

Plumego prefers explicit wiring:

• middleware order is code order
• request-scoped data is injected deliberately
• modules are composed visibly

The cost is a bit more wiring. The benefit is lower long-term complexity.

3) Fewer dependencies, fewer moving parts

Plumego is cautious about introducing hard dependencies.

Why:

• Dependencies change. Governance changes. Ecosystems fragment.
• The operational cost of upgrades increases with each dependency layer.
• Debugging becomes “framework archaeology” if the stack is too deep.

If you want an aggressively batteries-included platform, Framework X might deliver a better experience.

“But Framework X has feature Y…”

This is usually the core of the question. Here are the common ones.

Routing / groups / params

Plumego supports routing, groups, and parameters—but will avoid:

• overly clever route matching rules
• multiple competing param extraction APIs
• implicit bindings that obscure where values come from

If you need advanced routing features (complex patterns, subrouters, extensive middleware scoping), choose a router-centric ecosystem that already specializes in it.

DI (dependency injection)

Plumego does not force DI containers.

Reason:

• In Go, explicit construction is usually simpler and easier to test.
• DI containers often introduce indirection and lifecycle complexity.

If your org standardizes on DI and relies on container-managed lifecycles, Framework X (or a DI-first architecture) may reduce friction.

Validation / binding

Plumego avoids baking in a single validation/binding worldview.

Reason:

• These quickly become opinionated and “sticky”.
• Different teams want different tradeoffs: strict schemas vs. loose payloads, reflection vs. codegen, etc.

Plumego encourages:

• explicit JSON decode + explicit validation (or a chosen library you control)

ORM / database integration

Plumego intentionally avoids coupling “web runtime” to “storage runtime”.

Reason:

• Storage varies: SQL, KV, event sourcing, external APIs, hybrid.
• Tight coupling often causes cross-layer leakage (handlers manipulating DB sessions, etc.).

If you want a framework that “feels like an application platform” with strong ORM conventions, Framework X could be more productive.

Auth / JWT / sessions

Plumego supports the boundary and pattern, not a single “official” implementation.

Reason:

• Auth is where real-world complexity explodes (revocation, rotation, multi-device, tenant isolation, audits).
• Baking in a simplistic default can mislead teams into insecure designs.

Plumego prefers a clean seam:

• middleware parses/validates tokens
• usecases decide business rules
• stores handle sessions / revocation when needed

If you want a turn-key auth solution (and accept its constraints), Framework X may be better.

WebSocket / realtime

Plumego aims for a minimal, reliable base and clear backpressure semantics—not a full realtime product suite.

If you need:

• rooms, presence, fanout, broker integrations, durable messaging
  …you likely need either a dedicated realtime layer or a framework/ecosystem optimized for that.

The tradeoff you are actually choosing

This is the real decision axis:

If you choose “Framework X”

You often gain:

• speed to first endpoints
• more plugins and tutorials
• strong conventions that reduce decision-making

You may accept:

• more hidden behavior
• more dependencies
• harder upgrades in year 2–3
• less predictable performance under edge cases (depends on framework)

If you choose Plumego

You often gain:

• predictable request lifecycle
• simpler debugging and auditing
• fewer dependency constraints
• a foundation that remains understandable as the codebase grows

You may accept:

• more explicit wiring up front
• fewer “batteries-included” features
• more responsibility to choose or build integrations

When you should not use Plumego

Plumego is likely not the best choice when:

• You need a highly opinionated “application platform” with many integrated subsystems.
• Your team requires a mature plugin marketplace (auth, admin panels, scaffolding, etc.).
• You want the fastest ramp-up with the lowest engineering decision surface area.
• Your org standards mandate a specific framework for consistency/hiring.

In those cases, choose the framework that matches your constraints—do not fight them.

A practical decision checklist

Use Plumego when most of these are true:

• You care about long-term maintainability more than immediate convenience.
• You want minimal magic and maximum greppability.
• You expect frequent refactors and evolving domain boundaries.
• You want to keep the core close to net/http.

Choose Framework X when most of these are true:

• You need to ship quickly with a standardized stack and lots of plugins.
• You want strong conventions over flexible composition.
• You accept framework-specific patterns as the default architecture.

The respectful conclusion

Framework X is not “wrong”.
Plumego is simply optimizing for a different failure mode:

Plumego is built for the moment when your project is no longer small—and you still want it to feel simple.

If you want, you can link to dedicated pages that compare Plumego to specific frameworks:

• faq/plumego-vs-gin.md
• faq/plumego-vs-echo.md
• faq/plumego-vs-chi.md
• faq/is-plumego-for-small-projects.md