I compose APIs from Go and NodeJS servers and get really good productivity & performance benefits. And this is what I use; http://github.com/azer/atlas
It's resulted in a very straight forward go server implementation. The only package I use outside of the base go libraries is beego's session package.
That might be OK for some instances but many times, one needs to be able to serve a browser directly.
Your idea of a API is still a good one, you might just change the level at which you create this "backend" API.
So if you're a single guy writing everything by yourself, yeah you can also use your own programming language for both backend and frontend.
I write Go on the server to serve pages, and write rich front ends using simple javascript and jQuery. Being able to do nice quick page fetches means I don't get into massive complexity on the front end with a bloated single-page app, and not trying to deal with front-end complexity on the server means my server routes stay nice and simple.
I use Gocraft/web on the server because it's a useful library not an opinionated framework, and IMHO the most Go-idiomatic of the options (I tried them all and it was a toss-up between Gorilla and Gocraft/web, which won because of the really simple, useful context and middleware paradigm).
Creating API endpoints and page routes is simple and easy, and then writing the javascript to call endpoints when needed is simple (once I'd learned to stop jQuery from appending my data to the url and put it in the request body!).
My only gripe about the mix is that GoConvey doesn't integrate with Jasmine so I have to run two test suites.
Why? In fact, there's someone writing a Golang → Haxe transpiler, which is no less of a hack than CoffeeScript: http://tardisgo.github.io/
I think the majority of people attracted to go are fundamentally opposed to broad statements such as that one.
web frameworks do two things and they're terrible on both. they invent a lot of stuff that you'll likely try to get rid of a later time and it's gonna be too late since your codebase (both frontend and backend) is locked.
but API servers are not like that. they lead you the right (and the more productive) way; composing small libraries into something ideal for you. I'm not sure if it makes sense for people who tend to use frameworks but this works for me great. may be it's my taste
For example, a Java-based website designed this way would have two servlets -- one serving the JSON API and one templating servlet that consumes the JSON API and generates the page.
Another approach would be to forgo the templating servlet (or Rails/Django templating layer) and do all the rendering in a JavaScript client-side app that consumes the JSON API, but this can have SEO implications that may mean you also need to generate static pages for bot consumption (pjax can be useful here https://github.com/defunkt/jquery-pjax).