I wonder, what are the advantages of JS code generated by GopherJS over the one by TypeScript compiler?

<p>I don&#39;t know much about either of them.</p> <p>But here is a difference I&#39;ve noticed. There is a TypeScript code (I know that neither TS nor JS have <code>main</code> function, the code is just for demonstration):</p> <pre><code>function Add(a : number, b : number) : number { return a + b; } function main() { Add(1, 2); } </code></pre> <p>The compiler makes sure that <code>Add</code> is used correctly, arguments <code>a</code> and <code>b</code> are of number type and the number type is returned (otherwise, the compiler will show errors till you fix all the issues). But then it transpiles the code to the following JavaScript:</p> <pre><code>function Add(a, b) { return a + b; } function main() { Add(1, 2); } </code></pre> <p>Is my understanding correct, it checks types during &#34;compilation&#34; process but then generates a regular typeless JS?</p> <p>Meanwhile, GopherJS has a completely different behaviour. Here is a Go code fragment somehow equivalent to the one in TS:</p> <pre><code>package main func Add(a int, b int) int { return a + b } func main() { Add(1, 2) } </code></pre> <p>The generated JS is a 2351 LOC and ~69KB file. It is way more complex than TypeScript compiler&#39;s version and I guess, it should be slower. It implements the whole Go type system in JS, right? What are the advantages of this approach over transpiling Go ast to JS ast as-is?</p> <hr/>**评论：**<br/><br/>sh41: <pre><p>I&#39;ve been using GopherJS for a while and I&#39;m pretty familiar with its history, so I can answer this one.</p> <p>GopherJS started out more like a transpiler, where it&#39;d do something more akin to TypeScript compiler and create JS code that was roughly 1:1 to the Go code.</p> <p>However, the goal of GopherJS was to fully implement the entire Go spec and support the standard Go library. The challenge was in supporting the more advanced features like channels, goroutines, select statement, defer, goto.</p> <p>Also, to be able to compile standard library packages like io, bytes, strings, crypto/rand, reflect, net/http, fmt, etc., and all the basic types including interfaces, utf8 strings, runes, range loops, etc.</p> <p>To make all that possible, it was no longer viable to simply translate Go syntax to equivalent JS syntax, since many of the features of the Go spec I mentioned above do not have a direct equivalent in JS. That&#39;s how GopherJS evolved into a more sophisticated compiler.</p> <p>Creating a seemingly short package that imports fmt needs to include all the supporting code for Go types, and fmt package itself imports quite a few others [0]. However, as you add more lines of code to your program, the increase in generated output scales linearly with that.</p> <p>[0] <a href="https://godoc.org/fmt?import-graph" rel="nofollow">https://godoc.org/fmt?import-graph</a></p></pre>EclecticMind: <pre><p>What do you see as being the most common use cases for GopherJS today? </p></pre>nosmileface: <pre><p>Even though the question is not addressed to me. I think it&#39;s nice to demo your Go libs with GopherJS. I see no practical usage outside of that for it though. Maybe when WebAssembly becomes a thing. But for that it needs to become GopherWA.</p> <p>E.g. I wrote this lib called jsondiff and made a demo for it: <a href="http://nosmileface.ru/jsondiff" rel="nofollow">http://nosmileface.ru/jsondiff</a>, was pretty easy to do.</p></pre>earthboundkid: <pre><p>It&#39;s basically a toy project at this point. If you control the client so that file size is not an issue and you hate writing JS, you could use it so that you have isomorphic client/server code, but that&#39;s kind of a niche thing. Mostly, it&#39;s just cool.</p></pre>mastercactapus: <pre><p>I&#39;ve used it quite a few in for chrome apps; as far as I know it&#39;s the only way to get a fully functioning http server running IN the browser without writing your own. (the software for my CNC requires a websocket server on localhost, and I wanted to use my chromebook). I also used the standard libraries for a Go plugin in the atom editor (for parsing and whatnot), using gopherjs to build it into .js.</p> <p>It&#39;s definitely an edge case I&#39;d say (the http server); otherwise someone would have created one in (pure) javascript by now. Go lends itself well to portability that way. For a javascript-only environment gopherjs makes for a very convenient tool to leverage a lot of ready-made libs.</p> <p>In my case, nothing from the node.js core libraries was usable (they use native extensions); same for socket.io. but the Go net/http package didn&#39;t require extra work once you implement the required interfaces for the listener and connection, essentially making the entire project feasible.</p></pre>