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

41–50 of 82 posts

Re: Build desktop applications using Go and Web Technologies

#41

Post by dardeaup »

gen2brain wrote: post #20
miki123211 wrote: post #19

Earlier quoted context omitted.

Those are not native (on desktop) in any sense of the word. They don't use native controls. For that, you want WX or SWT, but those come with their own sets of problems. On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI). I'm personall…

I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though. https://github.com/gen2brain/iup-go

Impressive work!

Re: Build desktop applications using Go and Web Technologies

#42

Post by mnafees »

jdndbdhd wrote: post #38
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?

I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io. That said, I do not remember how we managed the lifetime but we did test it thoroughly before deploying to our initial beta users (or so we thought :P). The GC behavior started to happen whenever the app was in the background, which it was supposed to be for the majority of the time.

Re: Build desktop applications using Go and Web Technologies

#43

Post by mnafees »

arghwhat wrote: post #33
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 tras…

I totally agree :) I don't blame Go either. We were already a pure Go shop with a lot of focus on backend and infra systems engineering and were trying to venture into the desktop app market for our device monitoring software. Once we validated our idea with a rather buggy MVP haha, we quickly switched over to Electron and deployed on all 3 desktop OSes properly.

Re: Build desktop applications using Go and Web Technologies

#44

Post by dardeaup »

gen2brain wrote: post #20
miki123211 wrote: post #19

Earlier quoted context omitted.

Those are not native (on desktop) in any sense of the word. They don't use native controls. For that, you want WX or SWT, but those come with their own sets of problems. On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI). I'm personall…

I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though. https://github.com/gen2brain/iup-go

Does IUP have a table control? I looked at the IUP website and didn't see one.

Re: Build desktop applications using Go and Web Technologies

#45

Post by rubymamis »

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.

Indeed, I wrote my note-taking app using Qt with QML: https://get-notes.com

Re: Build desktop applications using Go and Web Technologies

#46

Post by lioeters »

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…

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.

Re: Build desktop applications using Go and Web Technologies

#47

Post by gen2brain »

dardeaup wrote: post #41
gen2brain wrote: post #20

Earlier quoted context omitted.

I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though. https://github.com/gen2brain/iup-go

Impressive work!

IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one. Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.

Re: Build desktop applications using Go and Web Technologies

#48

Post by piotr_bulinski »

p2detar wrote: post #39

Have a look at Fyne as well [0], which is a Go-only native UI toolkit. 0 - https://fyne.io Other discussions: - https://news.ycombinator.com/item?id=31785556 - https://news.ycombinator.com/item?id=19478079 - https://news.ycombinator.com/item?id=22291150

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 ;)

Re: Build desktop applications using Go and Web Technologies

#49

Post by adastra22 »

jasode wrote: post #24
adastra22 wrote: post #21

Earlier quoted context omitted.

Qt Quick Controls, React Native, and Xamarin.Forms all generate honest-to-god native controls. E.g. Cocoa, Win32 or Windows Presentation Forms, etc.

gp was using a more restrictive definition of "native controls". I.e. "o/s builtin UI controls" vs "framework canvas painted elements". For Windows, "native" would be the classic Win32 UI "common control" elements from "Comctl32.dll"[0] that is directly used by older GUI frameworks such as Windows Forms. Those map to classic Win32 API CreateWindow(L"BUTTON", ...) . In contrast, the newer frameworks of WPF and Xamarin…

I've never used Qt Quick so I learned something new. It's like Flutter then.

React Native and .NET MAUI/Xamarin.Forms use real native UI widgets - WinUI on Windows and AppKit on macOS.

Re: Build desktop applications using Go and Web Technologies

#50

Post by [deleted] »

adastra22 wrote: post #49
jasode wrote: post #24

Earlier quoted context omitted.

gp was using a more restrictive definition of "native controls". I.e. "o/s builtin UI controls" vs "framework canvas painted elements". For Windows, "native" would be the classic Win32 UI "common control" elements from "Comctl32.dll"[0] that is directly used by older GUI frameworks such as Windows Forms. Those map to classic Win32 API CreateWindow(L"BUTTON", ...) . In contrast, the newer frameworks of WPF and Xamarin…

I've never used Qt Quick so I learned something new. It's like Flutter then. React Native and .NET MAUI/Xamarin.Forms use real native UI widgets - WinUI on Windows and AppKit on macOS.

[deleted]
Post reply on HN