Showing my age, but until I read the full headline I thought this was a JavaScript client for the Gopher protocol...<p><a href="http://en.wikipedia.org/wiki/Gopher_(protocol)" rel="nofollow">http://en.wikipedia.org/wiki/Gopher_(protocol)</a><p>Time to pour one out for protocols loved and lost...
I've been using it for some time and it's really hard to believe how it just works for so many things.<p><a href="https://gopherjs.github.com/playground/" rel="nofollow">https://gopherjs.github.com/playground/</a> - GopherJS Playground.<p>(It compiles Go code to JavaScript in your browser using the GopherJS compiler itself compiled to JavaScript. There is no backend being used.)<p><a href="https://godoc.org/honnef.co/go/js/dom" rel="nofollow">https://godoc.org/honnef.co/go/js/dom</a> - DOM bindings.<p><a href="https://godoc.org/honnef.co/go/js/xhr" rel="nofollow">https://godoc.org/honnef.co/go/js/xhr</a> - XHR bindings.
I'd like to point out that goroutine support has been added which allows concurrency in the browser. You can literally avoid using callback soup using this.<p>its like clojure core.async only more powerful.
Can anyone speak to the trade-off in file size, for non-trivial codebases? There is a stated design goal of "small size of generated code", but the default snippet in the playground introduces quite a large amount of boilerplate. Is the penalty on file size fairly front-loaded or does the generated code scale horribly?
Is there any hope for a workflow similar to clojurescripts? It's very nice to have your page hooked to the repl and be able to re-evaluate pieces of code then have the page functionality change without constant refreshes and recompiles.<p>Edit: I want to expand on this a bit. I'm curious about how the workflow is now and what's envisioned. Things like the above mentioned and also LightTables insta-repl make for great workflow value propositions. I very much like Clojure, but I like Go as well and have written much, much more of it. So this is very interesting, but.. Do I need to write the Go code blind, then compile to js, then refresh and test my page to see what's going on?
Anyone know how hard it would be to get a ReactJS binding setup for this? I was literally just looking into GopherJS (for a normal frontend stuff) - but i'm unsure how gnarly it would be to setup bindings.<p>Part of me fears the output though. It can be rather verbose, large, and is quite abstract from the original code. Debugging and code-size worry me greatly.
I would say that's a great work. But, in order to write efficient code, you still need to understand both languages. It just saves you time to remember JavaScript syntax. Since we have google and stackoverflow, people can pretty much write more idiomatic code than machine. So the conclusion is not worth it.
For alternatives see (7 month old) : <a href="http://www.reddit.com/r/golang/comments/1z2bc4/a_transpiler_from_go_to_javascript_for_running_go/cfpxphl" rel="nofollow">http://www.reddit.com/r/golang/comments/1z2bc4/a_transpiler_...</a>
Why use a server-side language developed by Google (Go) as an alternative to JavaScript, when you could use a client-side language developed by Google and intended as an alternative to JavaScript (Dart)?