Something that when the rest of someone's computer is slowing down, this can stay responsive.
Not everyone has the fastest hardware or much ram; people like to have 100s of tabs open; and CPU's overheat and throttle, especially laptops.
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.
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:
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!
Yeah so without having to overwrite some very deep OS settings, which will likely raise some red flags for your app requiring administrator privilege to run, you aren't going to get this. If someone has a browser thats taking up most resources, its gonna throttle everything.
There is generally very little reason to write anything but web apps these days for things that don't need to touch specific hardware. If you stick to as much native js/css/html as possible (i.e avoid large libraries), it will load blazingly fast and use way less resources then web apps that are considered fast.
I think modern frameworks are so bad at perf because they assume people just have so much compute available and are focusing on one app at a time.
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)
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.
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.
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.
Qt is to PyQt and PySide as wxWidgets is to wxPython, roughly.
Check FLTK (Fast Light Tool Kit) too (C++).
