This also open the door to use ios7 JavaScript bridge from, right? Would be possible to write a iOS native app with go today?
GopherJS
31–40 of 42 posts
Re: GopherJS
#32I'm somewhat disappointed this has nothing to do with Gopher. http://en.wikipedia.org/wiki/Gopher_%28protocol%29
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...
Re: GopherJS
#33Earlier quoted context omitted.
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 visibl…
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 em…
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!
Re: GopherJS
#34I'm somewhat disappointed this has nothing to do with Gopher. http://en.wikipedia.org/wiki/Gopher_%28protocol%29
Same. I clicked hoping it was a Gopher client or server written in JS.
I am disappoint.
Re: GopherJS
#35Most 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` i…
The gxui package is super ugly. It has me wondering why they aren't implementing something for material design.
Re: GopherJS
#36Earlier quoted context omitted.
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...
Re: GopherJS
#37Most 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` i…
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:
Re: GopherJS
#38Whilst 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.
Re: GopherJS
#39Earlier quoted context omitted.
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
I saw that, and I found the answer unsatisfactory.
Re: GopherJS
#40Earlier quoted context omitted.
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
I saw that, and I found the answer unsatisfactory.
Feel free to comment on the issue explaining why, or make a PR.