

GopherJS - atomical
https://github.com/gopherjs/

======
blcknight
I'm somewhat disappointed this has nothing to do with Gopher.

[http://en.wikipedia.org/wiki/Gopher_%28protocol%29](http://en.wikipedia.org/wiki/Gopher_%28protocol%29)

~~~
emmanueloga_
I'm not disappointed but I agree the name is misleading / poorly chosen.

~~~
fnordsensei
"Go" wasn't a particularly bright name to begin with, when it comes to
googleability.

------
fabioberger123
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](https://github.com/fabioberger/chrome)

------
giaour
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.

~~~
shurcooL
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!

~~~
giaour
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.

------
alexchamberlain
Whilst I think projects like this are cool, it's a real shame that browser
vendors don't make embedding other engines easier.

~~~
tracker1
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.

------
tree_of_item
Any information on [https://tardisgo.github.io/](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.

~~~
thegeneral
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!

~~~
xiaq
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.

~~~
thegeneral
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!

------
shurcooL
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-...](https://github.com/gopherjs/gopherjs/issues/89#issuecomment-76564310)

[1]
[https://github.com/gopherjs/gopherjs/milestones/1.0](https://github.com/gopherjs/gopherjs/milestones/1.0)

[2]
[https://github.com/gopherjs/gopherjs/commit/fdbe407578d08ab7...](https://github.com/gopherjs/gopherjs/commit/fdbe407578d08ab76f9150277f68d01e45ee5f16)

[3]
[https://github.com/gopherjs/gopherjs/issues/121](https://github.com/gopherjs/gopherjs/issues/121)

[4]
[https://twitter.com/shurcooL/status/579395628683259905](https://twitter.com/shurcooL/status/579395628683259905)

[5] [http://dmitri.shuralyov.com/projects/gxui-
tree/](http://dmitri.shuralyov.com/projects/gxui-tree/)

[6] [http://dmitri.shuralyov.com/projects/Terrain-
Demo/](http://dmitri.shuralyov.com/projects/Terrain-Demo/)

[7] [http://dmitri.shuralyov.com/projects/live-markdown/live-
mark...](http://dmitri.shuralyov.com/projects/live-markdown/live-
markdown.html)

[8] [https://www.hakkalabs.co/articles/getting-started-
gopherjs](https://www.hakkalabs.co/articles/getting-started-gopherjs)

[9]
[https://news.ycombinator.com/item?id=8454604](https://news.ycombinator.com/item?id=8454604)

~~~
atomical
The gxui package is super ugly. It has me wondering why they aren't
implementing something for material design.

~~~
shurcooL
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)

~~~
atomical
I saw that, and I found the answer unsatisfactory.

~~~
shurcooL
Feel free to comment on the issue explaining why, or make a PR.

------
chimeracoder
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/#...](https://chimeracoder.github.io/full-stack-go-client-slides/#1)

[1] [https://github.com/gopherjs/jquery](https://github.com/gopherjs/jquery)

[2]
[https://github.com/gopherjs/gopherjs/issues/89](https://github.com/gopherjs/gopherjs/issues/89)

[3]
[https://github.com/gopherjs/gopherjs/issues/118](https://github.com/gopherjs/gopherjs/issues/118)

~~~
polymathist
> 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](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](https://github.com/gowade/wade).

~~~
egeozcan
There's also Wade[1], maybe you can merge efforts?

[1]: [https://github.com/gowade/wade](https://github.com/gowade/wade)

edit: I've just seen that you already mentioned it. I hadn't drunk my coffee
then, sorry!

------
alfonsodev
This also open the door to use ios7 JavaScript bridge from, right? Would be
possible to write a iOS native app with go today?

