Ask HN: What do you think is the current best Go webframework and why? - McMini
======
twotwotwo
Without making grand pronouncements about The Right Way, I at least get why
the Go community shies away from all-inclusive frameworks after years of using
Django. An all-inclusive framework is super helpful for getting started
quickly, but the way its components can be deeply tied with each other can
make life tricky when you want to do some things that weren't quite what the
framework authors envisioned. If you glued the components together yourself,
you at least know they're separable and where they fit together.

There are popular packages for the sorts of things that a lower-level Python
framework might:

\- [http://www.gorillatoolkit.org/](http://www.gorillatoolkit.org/) has a more
flexible router, sessions, and some other basics on the Web side

\- Built-in html/template is a pretty good place to start. (The context-aware
escaping is something I wish I had.)

\- Popular database tools include jmoiron/sqlx and jinzhu/gorm on GitHub.

\- gokit.io is mostly about internal services rather than frontends, but may
have parts of general interest. It includes example services.

\- godoc.org links to a bunch of popular packages and has search and such.
Incidentally, its own source is available:
[https://github.com/golang/gddo](https://github.com/golang/gddo)

I'd say Go is not going to get you to a releasable DB-backed Web app anywhere
near as fast as Django or any of the other well-known dyn-language frameworks.
I think the language has the bones where you could _get_ that sort of app to
faster time-to-first-usefulness, without entirely giving up the easy-to-
follow-what's-happening and pick-your-parts aspects, but probably not there
now.

~~~
ddw
While I agree with you and I tend to stay as lean as possible, it always
perplexes me why people want a Django/RoR/Phoenix in Go.

These other frameworks are mature and battle tested enough in agreeable enough
programming languages, why attempt to reinvent them in Go?

Go's strength and afaik original purpose for Google was for creating smaller
services, not a web app monolith.

~~~
twotwotwo
The wanting part I get: a lot of people do database-backed Web apps, some of
them (us!) see some useful attributes in Go and would like to have access to
them in our world too.

Personally I get that appeal more strongly now that in Django-land we're well
over 100K LOC and dealing with a lot more traffic and so on than when we
started. Helping folks scale gracefully from "tiny app you can get going very
soon" to "larger app that's still cool to maintain" might be where there's the
most unfilled need.

The truly hard part is figuring out what improvements you can achieve without
host/graft disease, where either the language itself or softer factors keep
the mashup from working satisfactorily.

That is, one way to fail at improving DB-backed webapps in Go is the obvious
one: you don't actually make them easy to build. Another is if you _do_ make
it easy to get started, but in the process lose the things that made it
appealing to use Go. Those might be "hard" technical attributes like static
checks and decent perf, or "soft" human- and standards-oriented things about
Go: flexibility in choosing libs you want, or norms favoring explicit code
where it's possible to work out what's really running from what's on the page.

Feeling out those tradeoffs is probably a long, communal process with a lot of
trial-and-error. Certainly it's slower and harder than just trying to
translate the dyn-language tools already out there. But I think it is possible
and could be really useful.

------
jwcrux
I prefer just using the standard library with a muxer like gorilla/mux.

~~~
peterbe
Because the more fully kithensunk ones are worse/bad/negative or just because
you keep it simple?

~~~
jwcrux
I prefer less opinionated where possible. "Worse" is really subjective, I just
don't need bells a whistles for many of my projects, so the stdlib is just
fine.

------
eternalban
OP's question is far too broad to elicit useful answers.

Start with a feature list of what you require from the framework.

    
    
        - Validation
        - Routing
        - Security
        - Filtering
        - Templating
        - Data binding
        - Component reuse
        ...

------
platzhirsch
I think the idea of a web framework in Go is too application level oriented
where as Go is a great language to write infrastructure. If you implement a
microservice, look for microservice frameworks. A web application itself seems
to broad. I would almost always recommend to find a custom implementation.

------
erikb
Really really close to flagging this. There is no "best X" for any X. At least
not without adding lots of context (and then it gets boring for other people
since these details probably are not interesting for them).

~~~
manojlds
If I am starting to learn Go and want to try my hands at building a web
service, what should I use?

~~~
randomdata
For learning purposes, I might suggest the Go implementation of gRPC[1]. As
the name implies, it is RPC focused and so doesn't necessarily translate well
to a complete web service (HATEOS and such), but still provides some insights
into how you might structure your code for that kind of project.

[1] [https://github.com/grpc/grpc-go](https://github.com/grpc/grpc-go)

