There seems to be a bit of traction around Revel: http://robfig.github.com/revel/

It was founded as a Play framework derivative, if you're familiar with that (I wasn't). I've been using it to put together a web service and I like it so far.

Revel is getting traction mostly among people who (like its author) are not very familiar with Go.

As gorilla http://gorilla-web.appspot.com/ and pat https://github.com/bmizerany/pat (by the creator of Sinatra) are much more in line with the Go philosophy.

The good (brilliant) thing about Play for Java, was that it wasn't inline with the Java philosophy.

So, Revel not being in line with the Go philosophy could also be a great thing.

>It was founded as a Play framework derivative, if you're familiar with that (I wasn't).

Play is a web framework for Scala and Java: http://playframework.org/ We've been very happy with it.

net/http together with Gorilla: http://gorilla-web.appspot.com/

Angularjs ;-)

Seriously, push your templates, models, and controllers into static client code (html/js) and use any of the dead-simple Sinatra-like clones to quickly scaffold your REST resources. Go is a superb "plumbing" language, in my opinion.

Unfortunately for a lot of applications that just doesn't scale.

In our case, I don't think our clients would be happy if we moved 2 million lines of code to the client-side...

It actually scales better because you're distributing the rendering effort on more machines.

You can serve client-side code on demand, the same way you're serving HTML on demand. There are multiple methods of running a rich client HTML application in a modular fashion. For example, you can load new JavaScript and CSS on demand, or you could do a hybrid approach, by reloading the complete page from module to module. Most MVC frameworks for JavaScript support dynamic loading.

It's still not practical. some other reasons:

1. It doesn't perform on some browsers which people use (IE7,IE8). I'm not willing to tell these users to go away or stick Chrome frame in as it makes us look like arrogant assholes.

2. It requires a large memory ceiling even with dynamic loading on a client browser. That kills older browsers and mobile devices.

3. It's an absolute bastard to test properly with Selenium or Ranorex as paths through the application require navigating through anchors rather than HTTP endpoints.

4. The entire UI would be dynamically typed shooting a lot of compile time checks that we rely on.

5. Internationalization is a bastard, particularly with multi-currency support, international date support and multiple languages.

6. It would require more state. State is bad. State means bugs.

7. It shifts the security model to an untrusted zone i.e. the client.

8. We have no scalability problems (5% cluster utilisation) and we shift 100 million requests a day.

Sorry but it doesn't cut it. I'd rather shift a WebStart or ClickOnce behemoth than do this with a client side MVC framework.

Yes, these are valid disadvantages of doing rendering code on the client. In your case, and many other similar to yours, using Go with abstract interfacing wouldn't be practical.

This is an interesting comment because I usually think of "scale" as being able to handle high load. Angular itself is itself about 500K (unminified), but still only about twice as big as jQuery (roughly). Regardless, it makes sense that client heavy apps aren't appropriate for all sites.