GopherJS(github.com)
github.com
GopherJS
https://github.com/gopherjs/
9 comments
I came here to say the same thing. I'd love some fresh effort spent on the protocol.
You may find a post I wrote entertaining. It talked a bit about 'taking back protocols' a few years ago.
Sorry for any broken links, I abandoned blogging due to toxic commenters.
http://cowbelljs.blogspot.ca/2011/12/lost-art-of-telnet.html...
Sorry for any broken links, I abandoned blogging due to toxic commenters.
http://cowbelljs.blogspot.ca/2011/12/lost-art-of-telnet.html...
You reminded me with your talk of MUDs of the growing IF (interactive fiction) movement. It's not multi-user, but it has a lot of the feel of those old text adventures. If that's interesting to you, I'd recommend trying out Blue Lacuna - http://blue-lacuna.textories.com/
Do you mind me asking why? I was going to implement the protocol as an intro rust project, but Wikipedia and others called it obsolete so I ended up falling back onto the familiar IRC bot. My interest is still piqued however...
Historical interest, mainly. Gopher is still used, but not by any large number of people; however, it occupies an interesting place in the history of the Internet as the main implementation of the idea of hypertext before the Web caught on.
They are just a bit confused with naming there at Google: Go, Gopher, Golang etc.
Go is the language name, golang is the search-friendly alt, and "gophers" are the users of the language. Your apparent distaste for Google doesn't justify your mean attempts at humour.
Java and Javascript walked into a bar...
I'm not disappointed but I agree the name is misleading / poorly chosen.
"Go" wasn't a particularly bright name to begin with, when it comes to googleability.
Perhaps GoJS or Go.js would be a better choice?
[deleted]
Same. I clicked hoping it was a Gopher client or server written in JS.
I am disappoint.
I am disappoint.
Just finished writing a Gopherjs binding for the chrome API so you can now write chrome extensions and Chrome apps in Go: https://github.com/fabioberger/chrome
I 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!
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.
Can you post an example? The playground doesn't seem to be working right now.
Whilst I think projects like this are cool, it's a real shame that browser vendors don't make embedding other engines easier.
It's plenty easy to embed another engine into a browser... see: VBScript, Dart, NaCl, etc...
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.
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.
Any information on https://tardisgo.github.io/ ? They target Haxe, so I guess they have a bit more ambition, but it does mean a lot more moving parts. It looks like GopherJS is more mature, though.
Hi, I'm the author of TARDISgo.
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!
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!
I am pleasantly surprised to find a Chinese sentence on the TARDIS Go website :) That sentence - "请发送一份汉语的电子邮件到作者" - is a perfectly comprehensible, but you can sound more Chinese. For the amusement of the Chinese-illiterate, I have included a word-by-word English translation of each sentence.
* 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.
* 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.
Wow xiaq, thank you for your kind explanation of how I can improve one of my Chinese sentences. I am always impressed by the way that well-written Chinese is so short - Mandarin is a wonderful language!
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!
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!
Upgrade to TARDISgo described above now released based on Haxe 2.3.0-rc2
Most 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
[9] https://news.ycombinator.com/item?id=8454604
- 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
[9] https://news.ycombinator.com/item?id=8454604
The gxui package is super ugly. It has me wondering why they aren't implementing something for material design.
If you're truly wondering, you're in luck. Someone already asked that question and it was answered:
https://github.com/google/gxui/issues/65
https://github.com/google/gxui/issues/65
Thanks, I missed [0] which really is awesome.
Edit: just looked at the webgl links, which is sweet.
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.
[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
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
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.
I think it will be extremely useful for games written in Go that run using WebGL/HTML5.
> 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 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.
I agree with that! Exciting times indeed.
I agree with that! Exciting times indeed.
> 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.
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.
There's also Wade[1], maybe you can merge efforts?
[1]: https://github.com/gowade/wade
edit: I've just seen that you already mentioned it. I hadn't drunk my coffee then, sorry!
[1]: https://github.com/gowade/wade
edit: I've just seen that you already mentioned it. I hadn't drunk my coffee then, sorry!
This also open the door to use ios7 JavaScript bridge from, right? Would be possible to write a iOS native app with go today?
[deleted]
http://en.wikipedia.org/wiki/Gopher_%28protocol%29