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.
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.