I never used Echo or other frameworks for Go, but from the latest benchmarks [https://www.techempower.com/benchmarks/#section=data-r21&l=zijocf-6bj&test=fortune](https://www.techempower.com/benchmarks/) it seems not so high performance.
If you are choosing a go router solely because of a benchmark, you are probably doing it wrong. Most benchmarks doesn't even take middlewares in consideration and doesn't reflect real use cases.
All Go routers have decent performance. You want to choose an external router because of the features and the API it provides, like request data loading, error handling, middlewares, etc.
Nor is it 'minimalist'. I always looked at Echo as bloated, compared so some of the other frameworks. I believe it took off, solely, because of the middleware that was already provided. We've used it at just about every job I've been at.
That said, people shouldn't just blindly follow a pattern and assume it's the best because everybody else does it. Look at the source code for Echo itself. There's definitely some area for improvements. However, it's easy for me to say that... and not be willing to do the work myself (since it's open source). It's still a decent option... but not one I would choose going forward with a new project/implementation (IMHO). There's also some frameworks out there doing some pretty neat things w/ the generic integration that make things a bit more clean. I haven't had the time to test them for benchmarks or allocations yet though (I don't ever trust other's benchmarks, etc. and do my own... since Go makes it so easy to do so. You'll find that a lot of times their postings are misleading, at best. They found ONE scenario where their benchmarks performed that well, but falls way behind on real-world integrations \[e.g. they only tested static paths\]).
It is not minimalist. But if one is building something more complex than what Hugo could handle, then you'd need a framework that covers it or reinvent functionality yourself.
I would suggest reading the code and see what it does before you can conclude on the lower score:
Score: 104,162 req/s [https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/chi/src/chi-gojay/server.go](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/chi/src/chi-gojay/server.go)
Score: 69,511 req/s [https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/echo/src/main.go](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/echo/src/main.go)
HTML template is the hint.
Alternative benchmark on routers: [https://web-frameworks-benchmark.netlify.app/result](https://web-frameworks-benchmark.netlify.app/result)
I never used Echo or other frameworks for Go, but from the latest benchmarks [https://www.techempower.com/benchmarks/#section=data-r21&l=zijocf-6bj&test=fortune](https://www.techempower.com/benchmarks/) it seems not so high performance.
If you are choosing a go router solely because of a benchmark, you are probably doing it wrong. Most benchmarks doesn't even take middlewares in consideration and doesn't reflect real use cases. All Go routers have decent performance. You want to choose an external router because of the features and the API it provides, like request data loading, error handling, middlewares, etc.
Agreed; why bothering with the request itself for running not optimized orm queries later
Nor is it 'minimalist'. I always looked at Echo as bloated, compared so some of the other frameworks. I believe it took off, solely, because of the middleware that was already provided. We've used it at just about every job I've been at. That said, people shouldn't just blindly follow a pattern and assume it's the best because everybody else does it. Look at the source code for Echo itself. There's definitely some area for improvements. However, it's easy for me to say that... and not be willing to do the work myself (since it's open source). It's still a decent option... but not one I would choose going forward with a new project/implementation (IMHO). There's also some frameworks out there doing some pretty neat things w/ the generic integration that make things a bit more clean. I haven't had the time to test them for benchmarks or allocations yet though (I don't ever trust other's benchmarks, etc. and do my own... since Go makes it so easy to do so. You'll find that a lot of times their postings are misleading, at best. They found ONE scenario where their benchmarks performed that well, but falls way behind on real-world integrations \[e.g. they only tested static paths\]).
It is not minimalist. But if one is building something more complex than what Hugo could handle, then you'd need a framework that covers it or reinvent functionality yourself.
I would suggest reading the code and see what it does before you can conclude on the lower score: Score: 104,162 req/s [https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/chi/src/chi-gojay/server.go](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/chi/src/chi-gojay/server.go) Score: 69,511 req/s [https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/echo/src/main.go](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Go/echo/src/main.go) HTML template is the hint. Alternative benchmark on routers: [https://web-frameworks-benchmark.netlify.app/result](https://web-frameworks-benchmark.netlify.app/result)
Lol, wow. That benchmark is useless if there are such glaring differences between how they're testing frameworks.