GopherJS
github.com
github.com
Sorry for any broken links, I abandoned blogging due to toxic commenters.
http://cowbelljs.blogspot.ca/2011/12/lost-art-of-telnet.html...
I am disappoint.
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!
The problem is that in the end, you won't see consensus on a secondary language from multiple browser vendors, in the end something that breaks down into JS/asm.js is probably more practical.
To me, getting webworkers to a better position of usability is a far better goal. As it stands, you have to write your worker completely detached from your main script/code... separate build target, separate calls, different model from node's IPC which reduces reusability. This is mainly in that I feel a bigger issue with JS performance for critical tasks in the browser will be alleviated by better channels with web-workers.
Yes, GopherJS is not only more mature, it is also a really great project. If you want to target JS today, you should use it.
By contrast, TARDISgo not only targets JS, it also targets C++, C# and Java (plus some other minor languages). In addition it gives access to the rich Haxe cross-platform development ecosystem.
I am actively developing the project, but that work is not yet visible on GitHub because of breaking changes in the Haxe compiler. The project will get a major upgrade once it is stable with the new version of Haxe (3.2.0). This upgrade will raise the number of standard packages which pass their tests (for at least one target language) to 80.
Major announcements about TARDISgo will appear on twitter @TARDISgo. Please stay tuned!
* Put the preposition phrase before the verb, which is the usual order. That turns "请发送一份汉语的电子邮件到作者" (please send a Chinese email towards author) into "请向作者发送一份汉语的电子邮件" (please towards author send a Chinese email). I have also changed the preposition from "到" to "向".
* Drop the unnecessary quantifier and "的". Chinese defaults on "a" most of the time, and "的" is often not needed for noun phrases. That turns "请向作者发送一份汉语的电子邮件" into "请向作者发送汉语电子邮件" (please towards author send Chinese email).
* Use "写" (write) instead of "发送" (send). The latter is a direct translation from English and not very native. Also "电子邮件" (email) can just be "邮件" (mail), especially when on-line. That turns "请向作者发送汉语电子邮件" into "请给作者写汉语邮件" (please towards author write Chinese mail). I have changed the preposition again, from "向" to "给".
* Prefer composite verb phrases over adjectives for describing means (here, the mail is written in Chinese). That turns "请给作者写汉语邮件" into "请用汉语给作者写邮件" (please use Chinese towards author write mail).
That's pretty it. Actually, "请用汉语给作者写邮件" is how I would write the sentence, and I figured out a path from your version towards mine :)
PS1. About the preposition changes - yes, "到", "向", and "给" all mean "towards" in this case, and I cannot really explain why I changed them. I can probably point to some literature if you are interested...
PS2. Another tiny detail: since you are already using the Chinese period mark "。" I recommend you also to use the Chinese question mark "？" in the previous sentence for consistency.
I have changed the web-site to use your revised wording. Thank you again for giving me such excellent and complete feedback.
When TARDISgo is fully ready, I hope you will give it a try, then write to me in Chinese to tell me how you get on!
- 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
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
I think it will be extremely useful for games written in Go that run using WebGL/HTML5.
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 agree with that! Exciting times indeed.
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.
[1]: https://github.com/gowade/wade
edit: I've just seen that you already mentioned it. I hadn't drunk my coffee then, sorry!