negroni

d GopherJS to run Go in the browser/frontend, but currently, a crazy experiment is all it is IMO... For serving dynamic content, the Go standard library comes with its own templating language and library: https://golang.org/pkg/html/template/ The standard library also comes with most of the tools you'll need for defining HTTP routes (see the server examples): https://golang.org/pkg/net/http/ Personally, I've found the following third-party packages to be quite helpful with putting together HTTP server-side apps in Go: - Gorilla mux for defining templated routes: https://github.com/gorilla/mux - Negroni for HTTP route Middlewares: https://github.com/codegangsta/negroni For testing HTTP server-side Go applications, the httptest package is quite helpful: https://golang.org/pkg/net/http/httptest/ As you can see, most of what you need just comes with the standard library, which is quite professionally designed and coded (reading through their source is a pleasure). The two external dependencies I mentioned are helpful, but not a strict requirement to build a server-side app. The main obstacle people have with using Go IMO has little to do with its ability to be used as a server-side language, and more to do with the nature of the language, and the consequences of its design choices. I think people who strongly prefer terse dynamic languages have trouble adopting/enjoying Go and its way of doing things. For instance, someone in this thread said that Go's structs and static typing makes it harder to work with JSON. You could also make the argument that this is a strength- all I have to do is declare a struct to specify what exactly I want to read from / write to JSON. Some people have complained about Go's verbosity. Sometimes they are right- certain things in Go take a little more text to express. I'm convinced that Go is a language that is more optimized for readability than for writability. You typically can't write "expressive" koans in a line of code... but your teammates probably have a higher chance (in my subjective opinion) of understanding the Go code you wrote a year after you've forgotten what you were thinking about. I could go on and on, but now I'm just fighting the eternal language holy wars :-) I hope I've given you a starting point for more research if you were considering Go for a server-side web application.