The workarounds one goes through to avoid native frameworks.<p>"Hands-On GUI Application Development in Go: Build responsive, cross-platform, graphical applications with the Go programming language"<p><a href="https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYSCT" rel="nofollow">https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYS...</a>
I just recently tried webview/webview in Go and was a little fed up with the fact that it could not be a single-binary plug & play experience on Windows. To that end, I am working on an experimental alternative that uses Webview2 directly without CGo: <a href="https://github.com/jchv/go-webview2" rel="nofollow">https://github.com/jchv/go-webview2</a><p>It still requires WebView2Loader.dll, but I am working on another library so I can just embed it directly into the application, and that work is happening over here: <a href="https://github.com/jchv/go-winloader" rel="nofollow">https://github.com/jchv/go-winloader</a><p>Sorry for the blatant self promotion, but I thought fellow stubborn people might have a desire to drop to as few dependencies as possible. I prefer building without CGo. The only downside is there’s not really a great way to fall back to EdgeHTML so users will need a Webview2 install, and right now Windows isn’t shipping it, but I think going forward it will be reasonable to just link users to the webview2 runtime page to go install it.<p>(Also, it should go without saying, but this approach only improves things on Windows. You will still need other bindings for other platforms.)
People complains about this setup but WASM is optional. I've been using Golang with Lorca <i>without</i> WASM. I actually don't see the value of WASM here.. Anyway, I used Svelte on the frontend, pretty straightforward but any other lib would have been as easy to bind. And it just... works.<p>The main advantage over Electron is the size of the bin (~20MB for a medium app vs. >100MB if it was Electron). If you know the people who are going to use your app have Chrome installed, it's definitely better than Electron and you get the best of both worlds - quick crafted & beautiful UI and performant backend
My problem with these approaches, is what's the next step? Do you implement GUI buttons on top of canvas and push pixels in WASM? Do you try and do something like ImGui and use WebGL? None of these approaches are efficient. If you are making a native app because it would be more efficient, I'm not sure what the point of this approach is.
Personally I'm a big fan of <a href="https://github.com/wailsapp/wails/" rel="nofollow">https://github.com/wailsapp/wails/</a><p>It uses native webview so no electron. Let's you effortlessly bind JS functions to those in Go.<p>V2 is in the works and will effectively bring the best features of electron window management (menus, frameless windows, drag regions etc) over to native webview.<p>Currently uses IE11 on Win 10 but V2 will only support Edge so you get WebKit across the board.
In general, why would one take this approach of embedding a browser, compiling to WASM, etc. over a native UI?<p>I'm genuinely curious why/when this is a better solution.
Carlo [1] was an exciting project to hear, sad that it's no longer maintained. Glad to see Lorca [2] as a spiritual successor.<p>[1] <a href="https://github.com/GoogleChromeLabs/carlo/" rel="nofollow">https://github.com/GoogleChromeLabs/carlo/</a><p>[2] <a href="https://github.com/zserge/lorca" rel="nofollow">https://github.com/zserge/lorca</a>
Cool article!<p>Small note: you can use rules_go's builtin go_embed_data [1] rule instead of rolling out your own using genrule.<p>1. <a href="https://github.com/bazelbuild/rules_go/blob/master/go/extras.rst#go_embed_data" rel="nofollow">https://github.com/bazelbuild/rules_go/blob/master/go/extras...</a>
I generally recommend Sciter for desktop apps; The programming model is extremely intuitive and straightforward, and in my experience, the performance is excellent. Besides that, I'd look at something like webview
Well done, I too am building a desktop app in Go, I couldn't find a decent GUI library and just resorted to packing a webserver & static files into my program instead. For the time being anyway, still looking for Gui options. Figured I could make a creative html/css UI instead of figuring out how to create a GUI. I'd like to mess with Qt but the GUI builder is with their paid licensing iirc i think, but it seems to be the only cross-platform solution afaik
Hello,<p>I'm super happy to see that some folks are trying to make apps with Golang.<p>I'm myself the author of a Go package to build GUI with WASM and Go => <a href="https://github.com/maxence-charriere/go-app" rel="nofollow">https://github.com/maxence-charriere/go-app</a><p>WASM give us an incredible amount of new possibilities and hopefully, we will get to a point where Go will be used in production also for GUI/apps purposes :)<p>Congrats for this and good luck for the future.
Knowing next to nothing about Golang: Is it unlikely that someone would ever develop an actual desktop toolkit for Golang? If so, how come?<p>From a naïve point of view, it would seem like overkill to run a whole web browser when a few kilobytes of memory is all it really takes to draw a widget on screen.
If one is using Go/C++/whatever WASM, why not go the extra step and use a binding framework for the OS's native UI toolkit, and just produce a native app? I don't understand with the fascination of bringing an entire OS (the browser) on top of an OS.
This is great but there many drawbacks.
I tried Qt but needed something native-er.<p>After much digging got to know about gioui[1] but it also has some issues.
Also Flutter[2] seems to be better fit but binding to golang is a little tough.<p>[1]: <a href="https://gioui.org/" rel="nofollow">https://gioui.org/</a><p>[2]: <a href="https://flutter.dev/" rel="nofollow">https://flutter.dev/</a>
Does this lead to a significantly smaller memory footprint than otherwise running .js in electron or a full browser?<p>I see you've become a big fan of bazel :)
<i>But I don’t want to write JavaScript(!) and deal with all the complexities that comes with it like npm, webpack, typescript… Fortunately, I can just compile GoLang to WebAssembly (WASM)</i><p>Okay...<p><i>Large WASM binaries (especially from GoLang): these take a long time to send over the network increasing loading times. In a desktop app the binary isn’t transferred over the network, so less overhead.</i><p>I forgot that you don't have to download desktop apps, they just appear!<p><i>Browser incompatibility: Some WebAssembly methods are unavailable in browsers and older browsers are not supported at all. In a desktop app the “browser” is controlled (Chrome for Lorca and Safari for webview), so no compatibility issues.</i><p>Electron???<p>This just seems like you built a less easy to use bundling/development platform than js/webpack/etc and claimed it was better when I'd argue it's way less mainstream and thus less accessible. Not to mention you could've just used native ui like others are talking about. Seems like the worst of both worlds to me.