Writing front end in Go

<p>So, as most people know, <a href="https://blog.gopheracademy.com/advent-2017/go-wasm/">golang will compile to wasm in 1.11 (July 31 release date)</a>. So, that begs the question, what UI technology do we use? Stick with the DOM? Web? I have a feeling the community will use the DOM at first, for obvious reasons, but I think WebGL merits discussion, as any browser supporting wasm or the js to which wasm compiles will also support WebGL. I don&#39;t know that for a fact, just speculating. In the long run, WebGL will be a strong choice, but it will take a lot more work up front. And that still leaves the question of search engine indexing...I think we would still need to mirror the text of the webpage into a hidden element in the DOM that is displayed by WebGL. These are all just thoughts to set the place for a discussion though. I&#39;m really wondering what the community is thinking.</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>We will stay with the DOM. The web won out as a UI platform for a reason and it isn&#39;t that we didn&#39;t have OpenGL available natively. It&#39;s that as much as there is a culture of contempt for it, it just is a good platform to build UIs.</p></pre>manifold360: <pre><p>Currently, we are using Go back-end providing REST services to an Electron front-end (React/Redux). Works fairly well.</p> <p>I will be building a prototype with webview/GopherJS/ReactiveX with simple React components with the goal of reducing the JS application code.</p> <p><a href="https://github.com/zserge/webview" rel="nofollow">https://github.com/zserge/webview</a></p> <p><a href="https://github.com/gopherjs/gopherjs" rel="nofollow">https://github.com/gopherjs/gopherjs</a></p> <p><a href="https://github.com/ReactiveX/rxjs" rel="nofollow">https://github.com/ReactiveX/rxjs</a></p> <p><a href="https://github.com/ReactiveX/RxGo" rel="nofollow">https://github.com/ReactiveX/RxGo</a></p></pre>kjk: <pre><p>WASM isn&#39;t designed to replace JavaScript as a way to modify DOM.</p> <p>That&#39;s why it currently can&#39;t even talk to DOM directly. To access DOM from WASM, you have to build a shim in JavaScript and call it out from WASM.</p> <p>WASM isn&#39;t designed to be used as a whole-sale replacement of JavaScript in a typical web app (games being a notable exception).</p> <p>The purpose of WASM is to allow you to write perf-critical parts of your code in a language faster than JavaScript and easily access this functionality from JavaScript.</p> <p>For example, if you were to write a converter of .rar archives into .zip archives on a web page, it would be very slow when implemented in JavaScript.</p> <p>With WASM you would still write almost the whole app in JavaScript but the time-critical parts of compressing/decompressing rar/zip would be implemented in C (or Go) and compiled to WASM and considerably speeding it up.</p></pre>SpiesWithin: <pre><p>I think wasm -&gt; DOM instead of wasm -&gt; JS -&gt; DOM is planned. </p></pre>zwhitchcox: <pre><p>Wow, that&#39;s a very interesting response, thank you for taking the time to respond to me! For me, though, I think it would still be better to have the whole thing in Go. I mean, I might fail (probably will fail), but I&#39;m going to see what I can come up with. I just like having the whole thing in the same language...that&#39;s why I started in JavaScript.</p></pre>darxkies: <pre><p>Don&#39;t give up. ;)</p></pre>soapysops: <pre><p>We definitely won&#39;t be replacing the DOM with WebGL. That would be terribly inefficient.</p> <p>Web assembly might eventually be used to let you control the DOM. It would be lovely to be able to write an entire app in Go, sharing the same data structures on the client and server.</p></pre>zwhitchcox: <pre><p>Hey, thanks for your response! I don&#39;t really understand how it would be less efficient. I thought WebGL would be less expensive than writing to the DOM. Could you please explain?</p></pre>hybsuns: <pre><p>I think wasm is the future. However, given that wasm is still in its early stage, I would still use a front-end framework (like React or Angular) for the front-end part, and Go for API only for now. Current front-end frameworks are not likely to be deprecated in a couple of years, so it will give you enough time to develop your project/product and make transitions to wasm.</p></pre>