Who is using GopherJS?

<p>Hello,</p> <p>I often read about GopherJS and I think it&#39;s a very cool project, but I have never seen it used. Are there any companies or projects know to use it? </p> <p>Thanks in advance!</p> <hr/>**评论：**<br/><br/>sin2pifx: <pre><p>Does anyone have experiences wrt GopherJS performance in the browser or nodejs in comparison to writing JavaScript directly? It&#39;s obvious that a large number of constructions map very closely, and in those constructions you would expect the exact same performance compared to writing in JavaScript (or TypeScript) directly. But there are a few obvious candidates that have some impact: arrays, &#34;generics&#34; (no need for type inspection in raw JavaScript; TypeScript can guarantee the type without overhead), and inheritance (prototype inheritance is much faster than adding an extra function that calls a function on an embedded struct field).</p> <p>The web doesn&#39;t have much to say on real usage cases. There was the surprising case where computing digits of pi was faster using GopherJS than using go run, but I&#39;m interested about the comparison between writing in Go and using GopherJS versus directly writing JavaScript, as it might offer a way towards a better performance for heavy tasks while keeping browser compatibility.</p></pre>xiegeo: <pre><p>Personally I prefer writing raw JS even if it means I have to use two languages. JSON serialization is very easy so I don&#39;t even have to redefine the data structures in js, there is very little code overlap. It also nicely separates my server code from the ui view layer. By serving js from file, I can save my js code and test in a browser immediately without any compilation stage. My Go code never need to know about DOM, and my JS code never touches SQL.</p> <p>If you do not know JS or really don&#39;t want to write JS or really need some code that can run both on the server and client, then GopherJS might work for you.</p></pre>scottjbarr: <pre><blockquote> <p>Personally I prefer writing raw JS even if it means I have to use two languages</p> </blockquote> <p>I&#39;m with you on this. In the end you&#39;re running JS on the front end so you might as well work with it. Alternatively you end up learning something else that has its own set of issues, that transpiles down to JS with its set of issues. </p> <p>GopherJS looks interesting, but I can&#39;t see myself using it. I&#39;m glad it scratches the itch for the author(s) and community. That&#39;s the fantastic thing about open source :)</p> <p><em>Please note I&#39;m not ragging on JS, every language, environment, whatever has its own particular issues.</em></p></pre>jns111: <pre><p>It&#39;s not about performance. It&#39;s about usability from a developers point of view. Want to build a modern spa with react or angular? Go get some &#34;bindings&#34; and hope things will work. Think of the myriad of options you&#39;ll get using webpack to bundle your web app. What about babel? What about browser compatibility? From a quick glance gopherjs looks similar to jquery&#39;s style of manipulating the dom. If you like it, ok. I personally prefer the declarative react style with redux. People put thousands of hours into developing stuff like react, react router and redux. With gopherjs you&#39;ll have to deal with bindings to be able to use these libraries. If you google &#34;gopherjs react&#34; you&#39;ll get vecty. They say it&#39;s experimental and api will change. I really like the idea of gopherjs. However, the way it&#39;s implemented just makes it useless to me because I have to drop too many advantages I would get using plain javascript. If you need server side rendering there&#39;s v8worker which does the trick for me.</p></pre>leftrightupdown: <pre><p>Once i considered writing go instead of js but i was put away by no web (think of jquery stuff) support from language that should run on web. Then i found about dartlang, also language by google. So far so good, great for writing large apps</p></pre>