Build desktop applications using Go and Web Technologies (opens in new tab)

> When we profiled it, we found that the GC essentially gave up under load

Hmm, the Go GC is really quite capable, so I wonder what kind of pathological load it was being presented with. Even then, when the GC "fails" it means elevated CPU load from collection.

The main thing I can think of would be the application "leaking" by having unintentional references (or worse, actually leaking through cgo bindings), or trashing the allocator to cause temporary spikes in between cleanups.

However, while I don't think Go was actually to blame here, I would never use native UI bindings to a language that isn't 1:1 compatible with the original design and memory management principles, as such bindings get disproportionaly large and complex. It just sets you up for a bad time.

Not wanting to discredit your experience, but that sounds very strange.

This sounds to me like leaking resources from the binding. Which binding did you use and how did you manage it's lifetime?

I actually did something similar: business logic and most things written in Go, but the menu bar or tray icon done in native APIs like Win32 and Gtk. It was surprisingly very good experience overall. I have tried so many ways around it before settling for that.

That is a surprising use case about Go and Electron (!), I would have imagined no contest for the superior performance of a compiled language, even with garbage collection. But the mention of "bindings for native UI frameworks", it was probably running the compiled code in a very tight loop, stressing the runtime. In contrast, Chromium specializes in UI with years of optimization.

Recently for a specific purpose I was reviewing options including Tauri, various WebView bindings, and in the end had to admit that Electron is probably the best approach in terms of feature set, development speed, etc.

> The Go bindings for native UI frameworks ended up being massive RAM hogs.

Which bindings did you use ?

Electron is quite bad on memory usage because it carries its own v8 environment on top of its own browser platform on top of using _another_ v8 environment for the nodejs part.

Tauri and Wails just use the one available in the OS (UIWebKit in macos, WebView2 in windows), it is also why they load so fast, you probably already have the heavy part loaded in memory. And, of course, brings a tiny statically linked binary instead of running on top of a massive runtime.

We recently did evaluation of different ways of building a cross-plarform desktop app as a Go team. We have built a PoC with Wails and Fyne, and we love Fyne. After a week from making a decision to go with Fyne, we are now 90% done and already running first alpha tests with users (who also love the simplicity of it). Devs like the ease of development and a ton of dependencies we don’t need to worry about, since Fyne is a lot leaner than Wails.

Just my 2 cents ;)

I did a project a few years ago with Fyne and it was excellent.

beta soon tm. mobile eventually with some PoCs around but nothing concrete yet sadly.

The OS's native rendering engine, there's no embedded browser. Here's a more detailed writeup https://wails.io/docs/howdoesitwork

Also very neat is DearImgui via either https://github.com/AllenDang/giu (Go-convenient wrapper) or https://github.com/AllenDang/cimgui-go/ (raw bindings)

Not all of us have the resources to write and maintain the same app 2 to 6 times.

because there is no proper UI library that does cross platform as well as the web

You might find this appealing:

https://github.com/mappu/miqt

Making good GUI software requires a lot of iteration and trial and error before you're satisfied with the UI and UX. With a web-based tech, you make a change, auto reload triggers, you see the change almost instantly, making tweaking very easy. If you're working with a large Qt codebase, every little change to a header file requires a long ass compile times. It's really frustrating when you spend an hour just tweaking a few controls when you know it could have taken 5 minutes. Also, the reactive model as seen in web frameworks like React or Vue is much superior to the typical flow of state management in retained mode GUI applications in desktop frameworks. Until we have a decent solution that solves these problems, people will continue using tech like Electron or OS web views.

But I already know how to write a web app, I don’t know how to write a desktop app. It’s faster to just write and wrap a web app, and as far as most people can tell, it works just fine.

Ya gotta be practical.

Fyne is a pretty decent native solution for doing this in Go.

When all that people want to use is how to use an hammer, they see nails everywhere.