Introduction: Comparing Frameworks Is Ultimately About Values

In technical communities, discussions of “Framework A vs Framework B” never seem to end.

But experienced engineers usually understand one thing clearly:

Framework debates are rarely about right or wrong technology—they are about value trade-offs.

Plumego was not created in a “blank market.”
On the contrary, it deliberately chose a seemingly “unattractive” path in an already thriving Go ecosystem.

Therefore, this article does not attempt to prove that:

• Plumego is “stronger” than other frameworks
• Plumego can replace all existing solutions

Instead, it aims to answer three more important questions:

1. What are the fundamental differences in design philosophy between Plumego and mainstream Go frameworks?
2. What engineering consequences do these differences lead to?
3. When should you choose Plumego—and when should you not?

1. Defining the Comparison: Who Are We Comparing Against?

In the Go web / service framework space, common choices generally fall into several categories:

1. Lightweight Web Frameworks (Most Common)

• Gin
• Echo
• Fiber

They typically offer:

• High performance
• Easy onboarding
• Comprehensive web abstractions

2. Full-Stack / Enterprise Frameworks

• Beego
• GoFrame

They are characterized by:

• Very broad functionality
• Many built-in components
• Strong conventions and tight integration

3. Infrastructure-Oriented / Cloud-Native Frameworks

• Go kit
• Kratos

They focus more on:

• Microservices
• RPC
• Observability
• Service governance

4. Direct Use of net/http (No Framework)

• Manually organizing routers and middleware
• Complete freedom
• Heavy reliance on individual experience

Plumego does not fully belong to any of these categories.

It is better described as:

“A carefully engineered skeleton layer built on top of net/http.”

2. Core Divergence #1: Standard Library vs Framework Abstraction

The Choice Made by Most Go Frameworks

Most mainstream frameworks choose to:

• Deeply wrap net/http
• Provide a “more convenient” context abstraction
• Hide parts of the standard library

The benefits are obvious:

• Fast onboarding
• Unified APIs
• Rich examples

But the costs include:

• Standard library behavior is reinterpreted
• Debugging requires understanding two semantic layers
• Framework upgrades affect critical paths

Plumego’s Choice

Plumego’s strategy is different:

It avoids redefining the standard library, and instead constrains how you use it.

In practice, this means:

• The HTTP server directly uses http.Server
• Context is extended from context.Context, not replaced
• Handlers remain explicit function calls

Plumego does not assume that:

“The standard library is inadequate and must be fully wrapped.”

Its underlying assumption is:

“The standard library is reliable, but engineering structure needs discipline.”

What Does This Mean in Practice?

3. Core Divergence #2: Implicit Magic vs Explicit Structure

Common Practices in Mainstream Frameworks

To boost developer productivity, many frameworks introduce:

• Automatic parameter binding
• Implicit JSON serialization
• “Catch-all” context storage
• Globally registered middleware

These designs are not “wrong”—they solve real problems.

But they share a common characteristic:

“They reduce short-term cognitive load while increasing long-term cognitive cost.”

Plumego’s Stance

Plumego is extremely restrained when it comes to implicit behavior.

In Plumego:

• Parameter parsing is explicit
• Error handling is deliberate
• Middleware order is fully traceable
• Context contents are enumerable

Plumego does not aim to:

“Write the least amount of code”

Instead, it aims to:

“Make changes with the greatest confidence”

A Key Litmus Test

One question clearly separates these two styles:

“When something breaks in production, which system would you rather debug?”

• One where behavior is hidden deep inside the framework
• Or one where every path can be traced line by line

Plumego’s answer is unambiguous.

4. Core Divergence #3: Feature Completeness vs Prunability

The Strengths and Costs of Full-Featured Frameworks

Frameworks like GoFrame and Beego provide:

• ORM
• Configuration systems
• Schedulers
• Caching
• RPC
• CLI tooling

Their advantages include:

• A true “one-stop solution”
• Rapid setup for business systems

The trade-offs are:

• Framework boundaries blur with business boundaries
• It is hard to adopt only a subset of features
• High cost of upgrading or replacing components

Plumego’s Design Position

Plumego intentionally remains “incomplete” at the capability level.

It is responsible only for:

• Request lifecycle
• Routing
• Middleware
• Context
• Handler boundaries

And it deliberately leaves the following to you:

• ORM selection
• Configuration systems
• Caching strategies
• Messaging systems
• Job scheduling

This makes Plumego more like:

“An engineering foundation that can be copied, trimmed, and evolved.”

5. Core Divergence #4: Short-Term Efficiency vs Long-Term Maintenance Cost

This is the most fundamental dividing line between Plumego and most other frameworks.

Frameworks Optimized for Short-Term Efficiency

They are:

• Excellent for MVPs
• Ideal for small teams and short cycles
• Great for rapid idea validation

However, risks increase when:

• Team members change
• Project lifecycles grow longer
• Architecture must evolve
• System complexity increases

Plumego’s Core Assumptions

From day one, Plumego assumes that:

• The project may live for many years
• Future maintainers may not be the original authors
• Structural changes are inevitable

As a result, it is willing to sacrifice some:

• “First-time coding excitement”

In exchange for:

• “Confidence when modifying code in year five”

6. Compared to Using net/http Directly, What Does Plumego Add?

A common question is:

If Plumego is so restrained, why not just use net/http directly?

This is an excellent question.

The Problems with Using net/http Directly

• Project structure varies widely by individual
• Middleware organization lacks consistency
• Context usage becomes ad hoc
• No “engineering-level default answers”

The Value Plumego Provides

Plumego does not write code for you. Instead, it:

• Provides stable solutions to recurring problems
• Introduces default constraints for project structure
• Establishes a shared baseline for team collaboration

You retain all the freedom of net/http, but you no longer have to reinvent structure for every project.

7. Use-Case Summary: Should You Use Plumego?

Plumego Is a Strong Fit If:

• You care about the ten-year lifespan of your code
• You do not want to be tightly locked into a framework
• You prefer engineering rigor over rapid assembly
• You are building foundational services or long-term systems
• You have deep respect for the Go standard library

You Probably Should Not Choose Plumego If:

• You need extremely fast MVP delivery
• Your team has limited Go experience
• The project lifecycle is clearly short
• You heavily rely on framework ecosystems and plugins

Conclusion: Plumego Is Not “Better,” Just “Clearer”

Plumego does not attempt to convince everyone.

It simply answers one question with clarity:

“If we are truly responsible for long-term maintenance, what should we sacrifice—and what must we insist on?”

In a world increasingly obsessed with speed, Plumego chooses a path that is slower, but controllable.

If you share this set of trade-offs, then Plumego is not a “new framework,” but an engineering answer you may have wanted for a long time—one that simply had not existed yet.