3 ms·

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop f

by cactus2093 7y ago

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm starting from scratch today trying to build a cross-platform app, what I'm looking for are frameworks that are mature, well documented with lots of tutorials on how to do basic things, and have a large community around them for getting help on e.g. stackoverflow. It doesn't really matter what has been around longer, if the newcomers have surpassed it on these fronts.

int_19h 7y ago
Qt would be an example of a desktop UI framework that was around 20 years ago, and is still popular today. It's also far more mature and stable than Electron etc, and better documented. I don't know whether there are more Electron apps these days around than Qt apps, but it's certainly neither outdated nor obscure.
PaulDavisThe1st 7y ago
Qt is already mentioned. GTK+ was also around 20 years ago (actually quite a lot more than that). For people dealing with media stuff, these days there's also JUCE though that is a relative newcomer. There was also FLTK, which I think it still around. Oh, and WxWidgets which was a very thin wrapper around the native GUI API on all 3 major platforms.
cameldrv 7y ago
Qt, Wx, GTK, Tk for starters.
yawaramin 7y ago
There was Delphi ... https://www.embarcadero.com/products/delphi https://www.embarcadero.com/products/delphi
rendall 7y ago
How do these older frameworks (Qt, etc) approach state management?
- PaulDavisThe1st 7y ago
  Well, first of all, the problem in its most basic sense doesn't even really exist for many places where you would use "Qt, etc". You wouldn't be reacting with a remote server or if you are you have a stateful connection with the remote server. That's true whether the "remote server" is just a database server or something more specific. But going somewhat deeper (and based on reading all the defenses of "React, etc" in the comments thus far), the fundamental difference is that if you were using a desktop GUI toolkit, you would almost certainly assume that there's essentially zero cost (or almost neglible cost) to the communication between the data (model) and the GUI. This is (one of the things) that is so different for web development, where everybody is struggling to optimize away roundtrips back to the data (server), because it actually costs. Put differently, whatever protocols might be implemented inside a desktop GUI to talk to a not-in-memory data source, the protocols are almost certainly designed for precisely that purpose. Whether its a vendor-supplied connection to an SQL database, an application-specific serialization/deserialization protocol, some IP-based message passing protocol ... whatever, it will all have been designed for the express purpose that it is being used for (more or less). HTTP? Ahem. Granted, web app development has augmented HTTP in various ways (most dramatically would probably be websockets/webrtc). But fundamentally, the state management issue in a web app originates with the fundamentally stateless communication protocol being used between the app and the data sources/servers it is dependent on.
  - acemarke 7y ago
    A few other differences: - The classic desktop GUI frameworks (Qt, wxWidgets, MFC, Swing, WinForms, etc) are based on a completely OOP inheritance and ownership model. You are responsible for instantiating widget instances, configuring them via setters, appending them to parents, and likely cleaning them up as well. - It's been long enough since I've done desktop GUI dev that I can't speak to the state management aspect much, but I can certainly say that at the time, my own programming understanding was limited enough that I would have said my "state" was "whatever items are currently inserted in that ListBox". (I knew that forms of data binding existed, but didn't grok them yet.) I do remember Swing's JTable widgets have a distinct MVC setup, at least. - Web dev is _heavily_ concerned with the number of bytes being delivered over the wire, so it's not just the number of round trips, there's the obsession with trying to find the tiniest library that can do what you need (combined with the nonexistent JS standard lib). With the desktop? Who cares, let's link in 50MB of Qt DLLs! (yes, yes, insert Electron joke here.)
Tehdasi 7y ago
The problem is that in the days before web UIs is also a different landscape in terms of the computing resources available, and the amount of security required. These were the problems that applications were focusing on solving. Because of this, the tools that developers were using were different, and don't make as much sense nowadays.

int_19h 7y ago

Qt would be an example of a desktop UI framework that was around 20 years ago, and is still popular today. It's also far more mature and stable than Electron etc, and better documented. I don't know whether there are more Electron apps these days around than Qt apps, but it's certainly neither outdated nor obscure.

PaulDavisThe1st 7y ago

Qt is already mentioned. GTK+ was also around 20 years ago (actually quite a lot more than that). For people dealing with media stuff, these days there's also JUCE though that is a relative newcomer. There was also FLTK, which I think it still around. Oh, and WxWidgets which was a very thin wrapper around the native GUI API on all 3 major platforms.

cameldrv 7y ago

Qt, Wx, GTK, Tk for starters.

yawaramin 7y ago

There was Delphi ... https://www.embarcadero.com/products/delphi https://www.embarcadero.com/products/delphi

rendall 7y ago

How do these older frameworks (Qt, etc) approach state management?

PaulDavisThe1st 7y ago
Well, first of all, the problem in its most basic sense doesn't even really exist for many places where you would use "Qt, etc". You wouldn't be reacting with a remote server or if you are you have a stateful connection with the remote server. That's true whether the "remote server" is just a database server or something more specific. But going somewhat deeper (and based on reading all the defenses of "React, etc" in the comments thus far), the fundamental difference is that if you were using a desktop GUI toolkit, you would almost certainly assume that there's essentially zero cost (or almost neglible cost) to the communication between the data (model) and the GUI. This is (one of the things) that is so different for web development, where everybody is struggling to optimize away roundtrips back to the data (server), because it actually costs. Put differently, whatever protocols might be implemented inside a desktop GUI to talk to a not-in-memory data source, the protocols are almost certainly designed for precisely that purpose. Whether its a vendor-supplied connection to an SQL database, an application-specific serialization/deserialization protocol, some IP-based message passing protocol ... whatever, it will all have been designed for the express purpose that it is being used for (more or less). HTTP? Ahem. Granted, web app development has augmented HTTP in various ways (most dramatically would probably be websockets/webrtc). But fundamentally, the state management issue in a web app originates with the fundamentally stateless communication protocol being used between the app and the data sources/servers it is dependent on.
- acemarke 7y ago
  A few other differences: - The classic desktop GUI frameworks (Qt, wxWidgets, MFC, Swing, WinForms, etc) are based on a completely OOP inheritance and ownership model. You are responsible for instantiating widget instances, configuring them via setters, appending them to parents, and likely cleaning them up as well. - It's been long enough since I've done desktop GUI dev that I can't speak to the state management aspect much, but I can certainly say that at the time, my own programming understanding was limited enough that I would have said my "state" was "whatever items are currently inserted in that ListBox". (I knew that forms of data binding existed, but didn't grok them yet.) I do remember Swing's JTable widgets have a distinct MVC setup, at least. - Web dev is _heavily_ concerned with the number of bytes being delivered over the wire, so it's not just the number of round trips, there's the obsession with trying to find the tiniest library that can do what you need (combined with the nonexistent JS standard lib). With the desktop? Who cares, let's link in 50MB of Qt DLLs! (yes, yes, insert Electron joke here.)

Tehdasi 7y ago

The problem is that in the days before web UIs is also a different landscape in terms of the computing resources available, and the amount of security required. These were the problems that applications were focusing on solving. Because of this, the tools that developers were using were different, and don't make as much sense nowadays.