Live data from Hacker News

Build desktop applications using Go and Web Technologies

github.com

21–30 of 82 posts

Re: Build desktop applications using Go and Web Technologies

#21

Earlier quoted context omitted.

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

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…

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

Re: Build desktop applications using Go and Web Technologies

#22
post #14

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.

"Native" seems to mean different things to different people. I'm mostly with you on this, but the tides are turning. In any case, the other 3 do use real native widgets.

Re: Build desktop applications using Go and Web Technologies

#24

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…

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 Forms and Qt Quick "paints controls on a canvas" which are not "native" and makes every app UI look different instead of standardized "look & feel" of common controls.

But others include custom-canvas painting UI objects as "native" -- as long as it's not Electron.

[0] https://learn.microsoft.com/en-us/windows/win32/controls/com...

Re: Build desktop applications using Go and Web Technologies

#25

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

Re: Build desktop applications using Go and Web Technologies

#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-so) Surprisingly, both the DX and UX improved significantly for our use case. Personally, I’d still prefer Swift/C#/C++ for native desktop work (coming from a Qt C++ background), but given the business constraints at the time, Electron ended up being the most pragmatic choice.

Re: Build desktop applications using Go and Web Technologies

#27
post #14

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 the word native doesn't make any sense anymore.

Re: Build desktop applications using Go and Web Technologies

#29

Earlier quoted context omitted.

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

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…

QT will mimick Win32 and Cocoa just fine.

Re: Build desktop applications using Go and Web Technologies

#30

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

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

Lazarus and Free Pascal and it will run several times faster than the web.
Post reply on HN