They both deviate from standard interfaces (eg. https://pkg.go.dev/net/http#Handler) and do their own thing. This is fine, but unidiomatic.
The Go community steers towards 'one way of doing things', meaning that packages that don't reuse established interfaces tend to be less popular compared to the ones that do (gorilla, chi, or just std).
I would argue that 'one way of doing things' is really at a much lower level, not at the package or module level. That was tied to "one way to loop, one way to place curly braces" Extending this idea to modules is not actually in line with how the GO team and community works.
Ah, I wasn't aware! It was heavily used a few years ago.
> Extending this idea to modules is not actually in line with how the ... community works
This is not my experience (with the community).
Packages that heavily reuse common interfaces (combinations of io.Reader|Writer|Closer|Seeker, http.Handler, http.ResponseWriter etc) tend to be more popular and recommended than packages that invent their own interfaces.
That is, unless the recommendation is just 'stick to the std', which has been a knee-jerk reaction from the community (reddit, slack) for a lot of problems, especially concerning new comers.
- it ships a pretty extensive collection of middlewares that will get you to 80% faster
- the documentation[2] is really well written and accessible to new web developers: most "must have" features have a cookbook page, so you don't have to google for blog posts.
- it does indeed use a custom handler function signature, but in my opinion this one is better (returning errors instead of handling them locally in each handler). You can still use handlers and middlewares written for other frameworks (for example the great statigz[3] handler) through the `echo.WrapHandler` and `echo.WrapMiddleware` functions
[1] https://github.com/letsblockit/letsblockit