<p>As we all know, Go has no official GUI standard library in release quality. Today, the GUI people seem to be divided into two camps: those pushing for native interfaces, and those telling that web is the real cross-platform future.</p>
<p>Since Go is pretty awesome at the web and native interfaces seem like less of a "natural fit" at this point, I was thinking: let's have the browser render the interface.</p>
<p>That left me with two basic options:</p>
<ol>
<li>On app start, start a self-hosted Go web server, then open a main web page that expects it to be running.</li>
<li>Use something like Electron to embed the app and then communicate with a Go web server.</li>
</ol>
<p>Option 1 actually turned out well! It was easy to get a pure Go solution going, with a little bit of platform-specific code as for how to open the web page in the user's installed, default browser (the "open .html in associated application" commands are OS specific). But after that, a pretty lean and neat solution!</p>
<p>I never actually tried Option 2 because of the ~100 MB bulk of such a method, having to embed a web browser and all. Sure, space is cheap but if there at all are alternatives I prefer not this way.</p>
<p>However, there was but one small problem.</p>
<p>Option 1 opens the page in the user's default browser which is <em>actually good enough for me</em>. All current Windows, macOS editions and Linux distros have good enough HTML5 + CSS3 support these days. The web nightmares are mostly over. Even Windows 10 has Edge pre-installed and it's good standards-wise. This is my main method to cut out the Electron bulk, yet still have the cake of a platform independent interface. I'll test my apps with different renderers, but CSS frameworks are already written with cross-browser support in mind.</p>
<p>However, and this is my issue, I lose the "app" feel. It just opens as a web browser tab. What would be awesome would be a cross-platform tool that embedded a web page in a chromeless browser, relying on an already existing Edge / Firefox / Chrome install (I think they all support embedding). Anyone know of such a thing? Then I'd just have my application first start the Go web server, then that "package". And my Go app would probably still be just in the single MB's. The best part of all would be everything in one. Server <em>and</em> client-side, a sort of "local web app bundle".</p>
<hr/>**评论：**<br/><br/>neoasterisk: <pre><p>To get the "app feel" do not use template/html. Instead write an API in Go then use your favorite front-end framework in pure HTML/JS/CSS to create a single page, "progressive" web app, full with a service worker, manifest etc. My personal recommendation is <a href="https://www.polymer-project.org/">polymer</a> and #UseThePlatform but any good framework will do.</p></pre>Generalj10: <pre><p>Ploymer is the answer here. Progressive web apps are fairly easy to build and you'll have a big community to help you out with components.</p></pre>mixedCase_: <pre><blockquote>
<p>However, and this is my issue, I lose the "app" feel.</p>
</blockquote>
<p>You would have to hard depend on Chrome/Chromium, but you can launch it in what's called "Application Mode".</p>
<p>Also I would call your problem a non-issue. For an app "feel", use a native toolkit or something like Qt.</p></pre>jugalator: <pre><p>Yes, I've considered Qt although there are some library and cross-compilation convenience reasons I want to stick with Go. Actually I'm OK as-is with running it in a browser tab, it's just that I was looking to at least get it to launch and run in its own chromeless window. Sometimes I would be, but in this case I'm not hell bent on sticking to native user interface elements.</p></pre>mixedCase_: <pre><p>There are some <a href="https://github.com/therecipe/qt" rel="nofollow">Qt bindings</a>, albeit hard to use.</p>
<p>With that said, one of my side projects has a Go application exposed via a websockets API to a QML frontend. Logically it requires some boilerplate, but it works.</p></pre>sh41: <pre><p>Can you elaborate on "Application Mode"?</p></pre>mixedCase_: <pre><p>From <code>man chromium</code>:</p>
<blockquote>
<p>--app=URL
Runs URL in "app mode": with no browser toolbars.</p>
</blockquote>
<p>And that's about it.</p></pre>iends: <pre><p><a href="https://github.com/murlokswarm/app">https://github.com/murlokswarm/app</a></p></pre>jugalator: <pre><p>Yeah this is the concept I'm looking for, thanks! :)</p></pre>PaluMacil: <pre><p>The problem I had with launching a chromeless browser was that if Chrome was already open, the flags were ignored and the link was simply opened in a new tab of the current browser. I don't think you'll get a pure go browsing solution better than that. Electron is heavy, but if you can't find something I missed with launching new browsers, you'll want to look at that or another form of Chromium Embedded Framework (CEF).</p></pre>jugalator: <pre><p>OK, yeah, seems like I'll end up with just keeping to open a tab by using a cross-platform "open" call where I basically just do <code>open http://localhost:8080/</code> when Go has started the local web server. That open command then does whatever necessary by using its association with URL's. On Windows 10, by default it'll add an Edge tab. On Debian, it adds a Firefox tab, and so on. It's not <em>terrible</em> and it's a way to not depend on various work-in-progress UI frameworks for Go or big embedded web browsers.</p>
<p>Edit: I'm doing like this right now</p>
<pre><code>package main
import (
"fmt"
"net/http"
"os/exec"
"runtime"
)
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])
}
func main() {
go open("http://localhost:8080/")
http.HandleFunc("/", handler)
panic(http.ListenAndServe(":8080", nil))
}
func open(url string) error {
var cmd string
var args []string
switch runtime.GOOS {
case "windows":
cmd = "cmd"
args = []string{"/c", "start"}
case "darwin":
cmd = "open"
default: // "linux", "freebsd", "openbsd", "netbsd"
cmd = "xdg-open"
}
args = append(args, url)
return exec.Command(cmd, args...).Start()
}
</code></pre></pre>Scaless: <pre><p><a href="https://bitbucket.org/chromiumembedded/cef" rel="nofollow">Chromium Embedded Framework</a> is probably your best option, at a minimum it's going to be 50MB to your distribution size. Good luck getting a fully featured HTML5 web browser in anything less than that.</p></pre>relvae: <pre><p>Every CEF bindings I've tried don't work cross platform or only support a very old version of CEF</p></pre>jugalator: <pre><p>Thanks, I think I saw that one but in this case I'm happy to embed an installed browser rather than bundle a browser. This is why I stayed clear of Electron, it just felt over the top for my needs to require a specific rendering engine.</p>
<p>At this point in time I have few issues with HTML5 + CSS3 and battle tested web development frameworks work across web browser engines, so my thinking was that I'd be fine with a wrapper that intelligently picks an already installed browser / rendering engine and uses that one. I mean, all main browsers happen to be embeddable today (?) and they all support these "modern" standards pretty well by now, so I'm not sure why I "must" have a bundled Chromium renderer when the web doesn't depend on a particular web browser to be installed. I've heard IE/MSHTML (not sure about Edge), Gecko, WebKit, Blink, all have API's for embedding.</p></pre>RalphCorderoy: <pre><p>How about a small piece of Javascript that spots it's running in a tab and uses window.open() to open itself, or a slightly different URL, in a new window with less browser furniture around the web pages? See <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Toolbar_and_chrome_features" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Toolbar_and_chrome_features</a></p></pre>snippet2: <pre><p>Man your post got so much more love then my comments here
<a href="https://www.reddit.com/r/golang/comments/5yl984/is_there_a_webassembly_compiler_for_go_in_the/" rel="nofollow">https://www.reddit.com/r/golang/comments/5yl984/is_there_a_webassembly_compiler_for_go_in_the/</a></p>
<p>It is a different topic but I'm jealous you got that going. :P</p></pre>chmikes: <pre><p>webassembly could change the "battlefield" in the next months and years. Not sure yet how Go would integrate it, but supporting local and remote display in a single app without the need to manage some code in go and other parts in javascript might be convenient. </p></pre>
