Sometimes I wonder if these framework astronauts have ever done a little Java Swing or VB GUI or the like. A user interface is not the greatest problem of our time...it's not supposed to be this hard...
You'd struggle to replicate most of that stuff in javascript even if you had days/weeks to do it. You'd be reinventing off the shelf components along the way that were completely bog standard 25 years ago; hand crafting event handling mechanisms; dealing with hard layout and positioning issues; etc.
That style of development seems to have died out for no good reason that I can think of other than that Javascript has been the only thing that actually works in a browser for the last 20 years. There's no other good reason for people to tolerate that.
Looking forward to WASM fixing that problem over the next few years. I might even get back to doing some frontend stuff.
On the other hand, the rise of cross-browser and cross-OS compatibility is really the root cause that drove a lot of this complexity from jQuery to React to even WASM, so you can't throw the baby out with the bathwater.
So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change.
Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results.
Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem.
What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API').
GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure.
But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.