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.
- 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.)
>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
Which is true, because model is what you’re working with and binding to (along with a controller). You can populate your models from a roundtrip data source, if it is not local. How is that different from web apps?
I think this is the good old “ancients were less smart” stereotype. Client-server and 3-tier apps didn’t begin with web. Heck, even lan latency/throughput/cpuclock were comparable to what modern internet timings impose.
Some of what you've said here strikes me as true, as long as you limit the domain to "applications" aka "database client-server front end foobars".
It's really not true for any desktops in the "creation" realms that I mentioned. The data model for an image manipulation program or a spreadsheet or a DAW or a document preparation system is fundamentally in memory, and there's no roundtrip to anywhere to access it or to modify it.
I suspect I’m repeatedly misreading this subthread then. My point is that web apps are still apps, no matter whether app data came from http or fs or sql. It is unclear why good old methods of slapping data controls together wouldn’t work and why is it so hard and esoteric to do fullstack today and learning curves are so steep even for a simple crud++ area.
I just thought of another critical difference when using "Qt, etc". These toolkits all have at their heart an event loop that looks something like:
while (!should_quit()) {
wait_for_user_input_or_other_events();
process_events(); // may mark some components for redraw
redraw_anything_that_needs_it();
}
So if user input or some data source indicates that some on-screen component now needs to be red with a yellow border, the "process events" stage makes a note of that, and effectively queues a re-rendering. The re-rendering takes place in the "redraw anything that needs it", at which time the code responsible for rendering can check current state and draw it red with a yellow border).
Quite a lot of what is "cool" about frameworks like React is the extent to which they are essentially trying to rebuild this fundamental event loop logic in a web app context.
It is pretty much the same, except there is no explicit loop and calls to wait for events written in JS/React code. Javascript itself runs a loop, instead of polling for events, you define events handlers, and DOM/React handles "redraw anything that needs it" part.
Just to be clear, the loop isn't explicit in a desktop toolkit either. You do not poll for events, and the toolkit handles the "redraw anything that needs it". So for example, in GTKmm (the C++ wrapper for GTK+), the event loop looks like:
Ah, it was quite a while since I looked at desktop GUI apps... It used to be just like OP described - you define logic, and then run pieces of it in the loop. It makes sense to abstract that away to standardize the process.
