11–20 of 27 posts
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:
If you want the fastest cross-platform native app. Build a native app for each platform and have the design teams review each other's work so everyone stays roughly on the same page. You're not going to hit your responsiveness goals otherwise. And it's not going to feel native otherwise (if anyone actually cares about that anymore, I dunno)
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 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.
If you want the fastest cross-platform native app. Build a native app for each platform and have the design teams review each other's work so everyone stays roughly on the same page. You're not going to hit your responsiveness goals otherwise. And it's not going to feel native otherwise (if anyone actually cares about that anymore, I dunno)
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?
He also has guest posts sometimes about/by other successful desktop software product creators. One of them was about Beyond Compare, a GUI file comparison tool, written in Delphi, IIRC.
I have read many of his blog posts, and they are quite interesting and informative.
Lazarus/Free Pascal, I've run the IDE on a Raspberry Pi Zero W, it wasn't anywhere near as fast as I'm used to on a PC, but it got the job done. It makes small compact efficient GUI and command line applications.
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 easy to pick up.
If you want the fastest cross-platform native app. Build a native app for each platform and have the design teams review each other's work so everyone stays roughly on the same page. You're not going to hit your responsiveness goals otherwise. And it's not going to feel native otherwise (if anyone actually cares about that anymore, I dunno)
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?
Qt is to PyQt and PySide as wxWidgets is to wxPython, roughly.
Check FLTK (Fast Light Tool Kit) too (C++).
Lazarus/Free Pascal, I've run the IDE on a Raspberry Pi Zero W, it wasn't anywhere near as fast as I'm used to on a PC, but it got the job done. It makes small compact efficient GUI and command line applications.
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…
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.
Microsoft can't seem to make up their mind on what UI platform people should be using. It's a mess. But they generally do support old platform, unlike Apple. I gag at thought of writing MFC code in 2024. But each to their own.
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.
Apple Nuke their entire developer ecosystem from orbit every few years. Using a cross-platform UI like Qt insulates you from this to an extent. But the downside is that you never get it to look quite 100% native and you may not have easy access to the latest bells and whistles from Apple. Microsoft can't seem to make up their mind on what UI platform people should be using. It's a mess. But they generally do support…
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.
Earlier quoted context omitted.
Apple Nuke their entire developer ecosystem from orbit every few years. Using a cross-platform UI like Qt insulates you from this to an extent. But the downside is that you never get it to look quite 100% native and you may not have easy access to the latest bells and whistles from Apple. Microsoft can't seem to make up their mind on what UI platform people should be using. It's a mess. But they generally do support…
>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.
If you want the fastest cross-platform native app. Build a native app for each platform and have the design teams review each other's work so everyone stays roughly on the same page. You're not going to hit your responsiveness goals otherwise. And it's not going to feel native otherwise (if anyone actually cares about that anymore, I dunno)
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 Windows, Microsoft has a history of releasing a new UI technology and then deprecating it. Their latest toolkit is WinUI 3. Given Microsofts dedication to backwards compatibility I think you could pick any of their toolkits, even the WinAPI. I should mention that WinUI 3 is an oddball because Microsoft is not shipping it with the OS, but rather vendors (you) must ship the toolkit with your app.
For Linux, the two most popular UI toolkits are GTK and Qt. But in truth Linux is just a kernel and it is the distro that decides what toolkit is "native". Maybe consider which distro(s) you'll target rather than treating Linux as a monolith.