Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build desktop applications using Go and Web Technologies

github.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Build desktop applications using Go and Web Technologies

#31

Post by throwup238 »

diath wrote: post #25
Exoristos wrote: post #2

The lengths we will go to avoid writing a proper desktop application.

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 tweakin…

It takes half a day to implement proper hot reload in QtQuick, which also has all the reactive features. Even less now that AI can just write it for you, and it’ll be more performant than Vite dev builds.

Coming to desktop app development from the web, I’ve got most of the same conveniences I’m used to like GammaRay as the inspector. The only real difference is I’m willing to wade through cmake and linking errors.

Even QWidgets is still super fast to develop with if you’re using PySide (although hot reload is a bit more difficult to implement and distribution becomes the nightmare).

Re: Build desktop applications using Go and Web Technologies

#32

Post by Kelteseth »

robert_dipaolo wrote: post #10
conceptme wrote: post #3

Earlier quoted context omitted.

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

What about QT? I've used that in the past and it's really good for native apps.

We are using it for our apps, but I can see why people do not use it for new projects:

1. The state of C++ is not great. Few developers, C++ footguns, complicated build systems, and generally slow progress, see my https://arewemodulesyet.org/

2. How Qt presents and licenses itself. Either you go LGPL or you have to pay big money for a commercial license, which will then infect all other apps as well. For example, when you have two Qt apps that talk to each other you must license _both_ commercially.

3. The split of Widgets and QML makes the ecosystem fragmented, because Widgets will never die. Even the Qt devs themselves are split about this. You can see this when example code for a new feature uses Widgets. QtCreator is also a nice example, where they reverted some new QML code quite a while ago and have not substantially added any new QML code since then.

4. Tooling: We use QML for everything and the tooling is not great. The language server is still super flaky and breaks, and developer tooling like the Chrome Dev Tools is virtually nonexistent.

5. Packaging is still also not great but has gotten better in the last few versions where Qt creates a deployment cmake script for you, but you still need logic for your own (vcpkg) packages.

Re: Build desktop applications using Go and Web Technologies

#33

Post by arghwhat »

mnafees wrote: post #26

We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron…

> 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.

Re: Build desktop applications using Go and Web Technologies

#34

Post by brulard »

mono442 wrote: post #14
adastra22 wrote: post #12

Earlier quoted context omitted.

There are quite a few. Qt, React Native, Xamarin, and Flutter come to mind.

I wouldn't exactly call Flutter native. It uses its own rendering engine and doesn't necessarily behave like operating system native controls. It is not really different from using electron.

Using electron at least uses some UI primitives from chromium. Flutter has thrown away all the usability and robustness of existing components and just reimplemented everything. It absolutely is different from electron

Re: Build desktop applications using Go and Web Technologies

#35

Post by brulard »

adamors wrote: post #5
hnlmorg wrote: post #4

What’s not clear to me for either the readme nor their website, is how does this actually work? With Electron, for example, a stripped down Chromium is shipped. So what does the web view rendering with this package?

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

so similar to Tauri?

Re: Build desktop applications using Go and Web Technologies

#36

Post by lenkite »

mnafees wrote: post #26

We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron…

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

Which bindings did you use ?

Re: Build desktop applications using Go and Web Technologies

#37

Post by gen2brain »

mock-possum wrote: post #9
Exoristos wrote: post #2

The lengths we will go to avoid writing a proper desktop application.

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.

To me, this argument always sounds like someone is being forced or threatened into creating a desktop app. It was never supposed to be easy; the goal is to create an app that users would want and will actually use.

Re: Build desktop applications using Go and Web Technologies

#38

Post by jdndbdhd »

mnafees wrote: post #26

We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron…

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?

Re: Build desktop applications using Go and Web Technologies

#40

Post by mnafees »

lenkite wrote: post #36
mnafees wrote: post #26

We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron…

> The Go bindings for native UI frameworks ended up being massive RAM hogs. Which bindings did you use ?

Been a while since I worked on it but I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io AFAIR.
Post reply on HN