Ask HN: Fastest cross-platform GUI stack/strategy • Hacker News Board

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#21

Post by fuzztester » Wed, Mar 20, 2024, 4:08 AM UTC

hermitcrab wrote: post #19

fuzztester wrote: post #18

Earlier quoted context omitted.

>I gag at thought of writing MFC code in 2024. In any year. Could never grok it, when it was newish, what with its crazy opaque AFX macros, although I could somewhat easily understand Win 32 C programming (Petzold book etc.), even though that was lower level, and I was new to event-driven GUI programming then.

The Win32 API is also seriously ugly. All those struct parameters, mostly full of zeros, and the hungarian notation. I know it is something from an earlier time and can't be changed without breaking everything, but it was hideous even by the standards of the day.

Yes, it was. Delphi, a few years later, was a lot better ...

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#22

Post by fuzztester » Wed, Mar 20, 2024, 7:36 PM UTC

api wrote: post #16

fuzztester wrote: post #14

Earlier quoted context omitted.

Yup. I've tested it for sizes of the generated binaries, versus C and Go, for a hello world program. C was smallest, next FP, last Go. Both C and FP were under 50 KB, IIRC. Go, much more, in the 1 MB range, IIRC. I have also written a few small CLI and GUI utilities in FP and Lazarus respectively, and it was mostly a breeze. Had fun. If you have Delphi or VB experience, it is very similar, conceptually, so fairly eas…

This is because Go bundles a big runtime in every binary.

Is there a way to not do that?

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#23

Post by valty » Thu, Mar 21, 2024, 1:36 PM UTC

toast0 wrote: post #12

valty wrote: post #7

Earlier quoted context omitted.

When I said "stack/strategy", the _strategy_ part implied this build-for-each-platform approach. The question still remains then of which to use for each platform. On macOS there is Cocoa (Swift or ObjC(++) or pure CPP) and Swift UI. On Windows there is .NET C# or CPP and a bunch of other stuff. Any thoughts?

For Mac, I'm not super in touch, but I get the impression Apple is all in on Swift UI, and their developer support model is clear: use old tech at your peril, it may not be supported in the next version. So I would use Swift UI. For Windows, I think it goes the other way. Microsoft is always coming around with a new UI model that's half-ass and will be dead next year. Use the old ways: MFC will never die.

I've heard a lot of horror stories with Swift UI.

I think it's crazy that it's closed source too. It's a big black box which makes debugging hard. Plus its the kind of framework that does a lot of magic stuff where you scratch your head wondering what is going on.

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#24

Post by mbalex99 » Thu, Mar 21, 2024, 9:50 PM UTC

valty wrote: post #23

toast0 wrote: post #12

Earlier quoted context omitted.

For Mac, I'm not super in touch, but I get the impression Apple is all in on Swift UI, and their developer support model is clear: use old tech at your peril, it may not be supported in the next version. So I would use Swift UI. For Windows, I think it goes the other way. Microsoft is always coming around with a new UI model that's half-ass and will be dead next year. Use the old ways: MFC will never die.

I've heard a lot of horror stories with Swift UI. I think it's crazy that it's closed source too. It's a big black box which makes debugging hard. Plus its the kind of framework that does a lot of magic stuff where you scratch your head wondering what is going on.

I wouldn’t say I’ve had horror stories just minor gripes and frustrations. You can mix and match AppKit and UIKit with SwiftUI. So there is always an escape hatch.

SwiftUI is insanely productive when it comes to building mostly simple list and form applications.

I highly recommend that you try it, you can always build a component or large sections using UIKit if you run into issues.

At Ditto almost all of our enterprise customers use SwiftUI over UIKit because SwiftUI is so productive for the vast majority of use cases. Does it have parity with UIKit? No… but it’s never been a dealbreaker for us.

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#25

Post by valty » Fri, Mar 22, 2024, 1:39 AM UTC

mbalex99 wrote: post #24

valty wrote: post #23

Earlier quoted context omitted.

I've heard a lot of horror stories with Swift UI. I think it's crazy that it's closed source too. It's a big black box which makes debugging hard. Plus its the kind of framework that does a lot of magic stuff where you scratch your head wondering what is going on.

I wouldn’t say I’ve had horror stories just minor gripes and frustrations. You can mix and match AppKit and UIKit with SwiftUI. So there is always an escape hatch. SwiftUI is insanely productive when it comes to building mostly simple list and form applications. I highly recommend that you try it, you can always build a component or large sections using UIKit if you run into issues. At Ditto almost all of our enterpr…

Yeh horror story was probably too strong a word. I need to try it.

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#26

Post by cookiengineer » Sat, Mar 23, 2024, 6:32 AM UTC

fuzztester wrote: post #22

api wrote: post #16

Earlier quoted context omitted.

This is because Go bundles a big runtime in every binary.

Is there a way to not do that?

You can also write allocation free Go, by computing everything on the stack. (Use pprof tool to analyze your code's allocations)

If you want smaller binaries without a runtime or GC bundled, you can try out tinygo [1]

[1] https://github.com/tinygo-org/tinygo

Re: Ask HN: Fastest cross-platform GUI stack/strategy

#27

Post by cookiengineer » Sat, Mar 23, 2024, 6:34 AM UTC

throwaway38375 wrote: post #11

I think HTML, CSS, and JS could be the answer here. However it relies on two important things: 1. Using something which uses the OS's built in browser (rather than something like Electron). 2. Keeping your JS very lightweight. This was shared a few days ago, combined with py2app could be a winner: https://github.com/r0x0r/pywebview

Personally I'd like to use github.com/webview/webview because they have bindings for a lot of languages (including golang) and use WebkitGTK behind the scenes on e.g. Linux distros.

With go you can embed all your assets and serve them on a local network port where the webview points to, which makes this combination ideal for fullscreen/kiosk like applications on older machines.

I am currently also trying out to build an opinionated UI library where I want to be able to reuse the defined structs on the client side (using web assembly), which would make interaction between clients and servers much easier. Not sure if I'm gonna be happy with it this way, but a man can only dream!