GopherJS
github.com
GopherJS
1–10 of 42 posts
Re: GopherJS
#2I'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.
[0] https://chimeracoder.github.io/full-stack-go-client-slides/#...
[1] https://github.com/gopherjs/jquery
Re: GopherJS
#3I'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…
Heh, I tried to post a link to GopherJS this morning but it got deleted I think(?).
I think it will be extremely useful for games written in Go that run using WebGL/HTML5.
Re: GopherJS
#4I'm somewhat disappointed this has nothing to do with Gopher.
Re: GopherJS
#5Most recent major GopherJS news:
- 29 days ago, the support for blocking calls became default, without needing to mark with `//gopherjs:blocking`. This was the last "not-really-Go" thing you needed to do previously. [0]
- There's a 1.0 milestone now, so Richard is getting closer to a 1.0 release. [1]
- Also recently, added support to make GET, POST requests via "net/http" (in browser) by providing a `net.Transport` implemented on top of XMLHttpRequest. [2]
- There's recent work on a "gopherjs serve" command to make development more convenient. [3]
I'm using GopherJS a lot.
Most recently, I ported google/gxui Go package to run in the browser [4]. You can try it here [5].
I've done some 3D stuff that works both on desktop and in browser by leveraging GopherJS. Here's a mini demo of that [6]. Hold down left mouse button and drag mouse to look around.
Here's a live markdown editor (and formatter) in browser, it uses existing Go packages. [7]
I gave a talk about GopherJS at previous GoSF meetup [8], which included some of these demos, and described the most common questions/concerns (debugging, file size, performance, general experience, advantages and disadvantages).
Previous discussion from 6 months ago [9].
[0] https://github.com/gopherjs/gopherjs/issues/89#issuecomment-...
[1] https://github.com/gopherjs/gopherjs/milestones/1.0
[2] https://github.com/gopherjs/gopherjs/commit/fdbe407578d08ab7...
[3] https://github.com/gopherjs/gopherjs/issues/121
[4] https://twitter.com/shurcooL/status/579395628683259905
[5] http://dmitri.shuralyov.com/projects/gxui-tree/
[6] http://dmitri.shuralyov.com/projects/Terrain-Demo/
[7] http://dmitri.shuralyov.com/projects/live-markdown/live-mark...
[8] https://www.hakkalabs.co/articles/getting-started-gopherjs
Re: GopherJS
#6I used this once to port some math-heavy Go and both amazed and aghast when I saw how int64 values were handled in the resulting javascript.
Re: GopherJS
#7I'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…
> 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.
Re: GopherJS
#8I used this once to port some math-heavy Go and both amazed and aghast when I saw how int64 values were handled in the resulting javascript.
Its primary goal is to follow the Go spec correctly, including simulating overflow/underflow on int64 type. Implementing that in JavaScript will have overhead.
So if you don't care about that, you can use int type instead, it will be faster.
But if you do care, I agree, using Go types is much much more pleasant and GopherJS takes care of that for you!
Re: GopherJS
#9I used this once to port some math-heavy Go and both amazed and aghast when I saw how int64 values were handled in the resulting javascript.
Its primary goal is to follow the Go spec correctly, including simulating overflow/underflow on int64 type. Implementing that in JavaScript will have overhead. So if you don't care about that, you can use int type instead, it will be faster. But if you do care, I agree, using Go types is much much more pleasant and GopherJS takes care of that for you!
I needed int64s and expected the js not to work in all cases. I was amazed at the ingenuity of the gopherjs team and aghast at the state of integer math in javascript.
Re: GopherJS
#10I'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…
> 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.
I agree with that! Exciting times indeed.