★ 88,666GoMITupdated Jun 2026
best for most teams; the default with the biggest middleware ecosystem and most Stack Overflow answers
Gin is the default, and defaults earn that status by being good enough for almost everyone, not by being the best fit for everyone. The radix-tree router is genuinely fast, the middleware model is a function that takes a Context and calls Next(), and gin-contrib already covers JWT, CORS, sessions, and rate limiting so you're not writing those yourself.
The catch is the Context object. It's your request, response, param bag, error collector, and render target all in one struct, and once you build anything non-trivial you'll find yourself writing adapters just to unit test a handler without booting the full framework. Structured error responses aren't built in either — every Gin codebase ends up with its own bespoke error envelope, and go-playground/validator's tag syntax turns unreadable fast on nested structs.
The '40x faster' claim in the README is measured against stdlib routing from before Go 1.22 added method-based matching. Against Echo, or against modern stdlib, the gap is a rounding error — pick Gin because your team already knows it, not because it's measurably faster than the alternatives here.
Our full take →GitHub ↗
★ 39,832GoMITupdated Jun 2026
best for developers coming from Express who want that API shape, plus fasthttp-level raw throughput
Fiber is for people who already think in Express and don't want to relearn routing syntax to get to Go. It's built on fasthttp instead of net/http, which is where both its throughput numbers and most of its problems come from.
fasthttp skips the standard library's connection handling, so you inherit non-standard HTTP/1.1 behavior that has caused subtle bugs against certain proxies and clients — something Gin, Echo, and chi never have to think about because they're all on net/http. HTTP/2 needs a separate contrib package instead of being built in, and the README itself admits the unsafe tricks behind its zero-allocation Ctx mean Fiber tends to trail new Go releases.
v3's net/http adapter helps with the ecosystem isolation, but now there are three different ways to write a handler in the same codebase — Ctx, the newer Req/Res pair, and adapted net/http — with no house rule on which one new code should use. Session and cache middleware pull in gofiber/storage on top, another dependency surface Gin and Echo don't ask you to manage.
Our full take →GitHub ↗
★ 32,446GoMITupdated Jun 2026
best for teams who want a small, stable core and build their stack from clean middleware rather than framework magic
Echo is the answer for teams who got burned by magic somewhere else and want a small, boring core to build on top of. The router handles trailing slashes and conflicting routes more sanely than most alternatives, middleware scoping is clean at the group level, and the echotest package lets you test handlers without spinning up a real server — something Gin makes you work for.
What it doesn't give you is Beego's or GoFrame's ORM and config story, or Iris's DI container — that's the deliberate trade. The built-in rate limiter only tracks state in memory, so the moment you run two instances it's useless and you're replacing it anyway. There's no OpenAPI generation either, so you're reaching for oapi-codegen or swaggo on day one of any real API, and your route code and your spec drift apart over time.
V5's generic context additions read like they were added after the fact rather than designed in, and the V4-to-V5 upgrade guide is long enough to be an afternoon project, not a point release. WebSocket support exists but is thin past the basic chat-example level — budget time to write the reconnect and framing logic yourself.
Our full take →GitHub ↗
★ 22,131GoMITupdated Feb 2026
best for developers who want a router that stays on net/http's types instead of inventing its own
chi's whole pitch is that it adds almost nothing — a router built on a radix trie, route groups, and param extraction, all still typed as plain net/http.Handler. Every middleware written for the standard library works here with zero adapter code, which is more than you can say for Fiber or Hertz.
The cost of staying that thin is that chi stays thin. URL params come back through chi.URLParam, a string lookup against context.Value on every call, with none of the typed binding Iris gives you at the router level. The bundled Timeout middleware sets a deadline on the context but doesn't stop an in-flight write or close the connection — you still have to check ctx.Done() yourself, and it's easy to forget. Default logging is plain text; anything structured means pulling in httplog separately.
The benchmark numbers in the README are from 2020 on Go 1.15. Go 1.22's stdlib ServeMux got method-based routing since then, closing most of the gap chi used to have over doing nothing at all — if you're picking chi for speed rather than for staying close to net/http, check that math first.
Our full take →GitHub ↗
★ 25,581GoBSD-3-Clauseupdated Jan 2026
best for teams that want MVC, sessions, and i18n built in instead of assembled from separate packages
Iris is the one framework here actually trying to be ASP.NET Core rather than idiomatic Go — MVC routing, a real DI container, sessions, i18n, and multiple view engines, all built in rather than assembled. If you want Beego's full-stack philosophy with a nicer DI story, this is it.
That ambition comes with real baggage. The 'fastest HTTP/2 framework' claim in the README is backed by benchmarks from 2020, and current numbers from Gin, Echo, or stdlib tell a different story. The project also has a documented history of license and attribution disputes with the Go community — not a small thing to explain to legal before shipping a commercial product on it.
It's a single-maintainer project with no company behind it, so 'lifetime active maintenance' rests on one person's continued interest — check the commit graph before betting a production service on it. And because the MVC/DI model fights how Go developers are used to composing code, onboarding anyone from a chi or Echo background means unlearning habits, not building on them.
Our full take →GitHub ↗
★ 7,267GoApache-2.0updated Jun 2026
best for teams needing proven throughput at ByteDance-scale traffic
Hertz exists for one reason: ByteDance needed something that could handle their traffic, so they built their own network layer, Netpoll, instead of trusting Go's net package. If you're nowhere near that scale, the other seven frameworks here will serve you fine with less risk.
The tradeoff is real. Netpoll doesn't support Windows — if anyone on your team develops there, they silently fall back to plain Go net without being told, or hit build failures they have to debug themselves. HTTP/2 and WebSocket both live in separate contrib repos rather than core, and those repos lag the main project, so anything past HTTP/1.1 is maintenance risk you're taking on.
The community and most of the documentation are Chinese-first, so when something breaks at 2am and you don't read Chinese, you're troubleshooting at a real disadvantage compared to Gin or Echo's English-language Stack Overflow presence. The hz code generator and service-discovery integrations assume a Thrift/ByteDance-style stack, which feels foreign coming from a standard gRPC or REST setup.
Our full take →GitHub ↗
★ 32,427GoNOASSERTIONupdated Sep 2026
best for teams wanting Rails-style full-stack conventions with ORM and admin tooling bundled in
Beego is the Rails analogy taken seriously — MVC, an ORM with five real backends, sessions, caching, and config bundled as one package, for people who don't want to assemble net/http plus a router plus six separate libraries. The cache client alone, with read-through, write-through, singleflight, and a bloom filter, has more thought in it than most standalone Go cache packages.
The documentation is the dealbreaker. The README itself says the official doc site is unavailable, points you to a third-party mirror, and warns you'll hit an expired HTTPS certificate warning getting there. For a framework asking you to adopt its ORM, its config system, and its session stack as a package deal, having no reliable primary docs isn't a small gap — it's the difference between evaluating Beego and giving up after twenty minutes.
The MVC and annotation-router conventions also read like a port from a different ecosystem rather than idiomatic Go, a real adjustment if your team is used to chi or Echo's composable style. You're not picking a router here, you're picking an ini-config, ORM, and session stack all at once — fine if you want that, a lot of lock-in if you don't.
Our full take →GitHub ↗
★ 13,189GoMITupdated Jun 2026
best for teams wanting one enterprise toolkit (router, ORM, cache, config) instead of wiring up separate libraries
GoFrame is the other full-stack contender, and it's more enterprise-generic than Beego — routing, ORM, config, logging, tracing, and caching all under one roof, with a CLI that generates DAOs and controllers straight from your database schema. The built-in OpenTelemetry wiring across HTTP, ORM, Redis, and logging is a genuine advantage over Echo or chi, where you'd instrument every layer by hand.
Like Beego, the documentation is Chinese-first and the English translation lags — budget time to hit pages that are machine-translated or missing outright. The bigger issue is the global-singleton pattern: g.DB(), g.Redis(), g.Cfg() create implicit shared state across your app, which makes testing awkward unless you use GoFrame's own test helpers, and it's easy to misuse without noticing.
It's monolithic the same way Beego is — adopt the HTTP server and you're also adopting their logger, their config, their ORM, and their own types threaded through all of it, so swapping any one layer out later is painful. The gf CLI's code generation is opinionated enough that it expects a specific project layout and will fight you if yours doesn't match.
Our full take →GitHub ↗
// questions people ask
Before you choose
Should I just use Go's standard library instead of any of these?
If you're on Go 1.22 or newer, net/http's ServeMux now does method-based routing and pattern matching, which covers what a lot of teams used chi or Gin for. It's still missing middleware chaining, grouped routes, and JSON binding helpers, so for anything beyond a handful of endpoints you'll end up rebuilding what chi or Echo already give you.
Which of these is actually the fastest?
Fiber and Hertz, because they skip net/http for fasthttp and Netpoll respectively — but the gap only shows up under genuinely high concurrency, not typical API traffic. For most teams, Gin, Echo, and chi are close enough to each other that router speed shouldn't be the deciding factor.
Which framework plays nicest with existing net/http middleware?
chi, Echo, and Gin all use net/http's types directly, so any existing middleware works without adapters. Fiber added a net/http adapter in v3 that helps but isn't complete, and Hertz's Netpoll-based core needs middleware written specifically for it.
Is Gin still the right default in 2026?
For most teams, yes — not because it's fastest, but because the ecosystem (gin-contrib, Stack Overflow answers, hiring pool) is bigger than any of the alternatives. If you specifically want a smaller, more testable core, Echo is the better default; if you want to stay closest to net/http, pick chi instead.
None of these choices are wrong, they're just different bets on where you want your risk — in your dependencies, your runtime, or your framework's opinions. If picks like this are useful, the weekly finds.dev email runs the same way: one real take per repo, including the parts that don't make the README.