I've used GopherJS. I actually gave a talk just this past week about full-stack Go[0] (ie, using Go for native mobile/desktop, and client-side web development in addition to server-side), and GopherJS was, unsurprisingly, a bit part of that.
GopherJS works surprisingly well; the biggest issue for most people will be the unminified file size. But based on my initial profiling, between minifiers, caching, and the fact that many websites are serving large assets (images) already, it's less of an issue than I had anticipated it would be.
The second biggest issue is the fact that almost nobody writes raw Javascript anymore these days in the browser. Most people use not only JQuery (or a similar tool), but something to structure client-side code, like React.js or Angular.js.
GopherJS has an implementation of JQuery[1], which works about as well as JQuery itself does - that is, it does the job, but can get unmaintainable when there is a lot of client-side code. There is a GopherJS implementation of Angular.js, though I haven't used it.
Until a month ago, there was a lingering quirk with the way GopherJS handled asynchronous code (calls to blocking functions had to be specially marked with comments, which meant that parts of the standard library couldn't be used be used without modification). They just fixed this a month ago[2], which is a huge milestone for the project.
React is a bit trickier, given the way that React applications are structured, and the way that React interacts with Javascript-specific features (namely the "this" keyword). It's currently usable, but with insane filesize[3]. I think this could be slimmed down, since almost no work has been done optimizing this so far, but React-on-GopherJS is certainly not production-ready yet.
That said, that's only looking at compiling existing Javascript code to Go. My hope is that the next client-side MVC/MVVC/etc. framework will be written in Go from the start. Go is a great language for structuring client-side code; the only bottleneck (until now) was that there was no way of actually running the code! But now that GopherJS is in a working state, it's a completely green field - very exciting time.
> My hope is that the next client-side MVC/MVVC/etc. framework will be written in Go from the start.
A friend and I are working on exactly that! It's called humble: https://github.com/soroushjp/humble. We took a lot of inspiration from backbone and react. Still in an experimental phase and hasn't been touched much since we built it for the Gopher Gala, but we have plans to work on it a lot more in the future. There is also https://github.com/gowade/wade.
> the biggest issue for most people will be the unminified file size
I wanted to write my validation logic in Go and use that at the client side too, in a React app. Size was indeed my biggest problem. Gzipped size was around 60KB, and that's after the closure compiler advanced level minification. It would make sense if the whole app was being written in Go but having a JS channels implementation transferred through the wire, only never to be used is a bit too much for sharing simple code. I hope that this project becomes very successful and the output gets further optimized.
I still think gopherjs should emit code compatible with and annotated for the google closure compiler. The fact that go programs have all source present, and are statically typed, means it could emit some tiny code.
> My hope is that the next client-side MVC/MVVC/etc. framework will be written in Go from the start. Go is a great language for structuring client-side code; the only bottleneck (until now) was that there was no way of actually running the code! But now that GopherJS is in a working state, it's a completely green field - very exciting time.
GopherJS works surprisingly well; the biggest issue for most people will be the unminified file size. But based on my initial profiling, between minifiers, caching, and the fact that many websites are serving large assets (images) already, it's less of an issue than I had anticipated it would be.
The second biggest issue is the fact that almost nobody writes raw Javascript anymore these days in the browser. Most people use not only JQuery (or a similar tool), but something to structure client-side code, like React.js or Angular.js.
GopherJS has an implementation of JQuery[1], which works about as well as JQuery itself does - that is, it does the job, but can get unmaintainable when there is a lot of client-side code. There is a GopherJS implementation of Angular.js, though I haven't used it.
Until a month ago, there was a lingering quirk with the way GopherJS handled asynchronous code (calls to blocking functions had to be specially marked with comments, which meant that parts of the standard library couldn't be used be used without modification). They just fixed this a month ago[2], which is a huge milestone for the project.
React is a bit trickier, given the way that React applications are structured, and the way that React interacts with Javascript-specific features (namely the "this" keyword). It's currently usable, but with insane filesize[3]. I think this could be slimmed down, since almost no work has been done optimizing this so far, but React-on-GopherJS is certainly not production-ready yet.
That said, that's only looking at compiling existing Javascript code to Go. My hope is that the next client-side MVC/MVVC/etc. framework will be written in Go from the start. Go is a great language for structuring client-side code; the only bottleneck (until now) was that there was no way of actually running the code! But now that GopherJS is in a working state, it's a completely green field - very exciting time.
[0] https://chimeracoder.github.io/full-stack-go-client-slides/#...
[1] https://github.com/gopherjs/jquery
[2] https://github.com/gopherjs/gopherjs/issues/89
[3] https://github.com/gopherjs/gopherjs/issues/118