[monarchwadia]

Well, in React specifically, you're describing the Flux architecture, which I've implemented manually back in the day. Its modern-day successor is Redux, which does exactly what you describe, but we found that it introduced more complexity rather than remove it.

I don't know about the other UIs, but on the web, some things impinge on the model you (and Redux) are proposing.

One thing is: you, in the gamedev world, have the luxury of having a frame buffer to write to. You fully control what gets rendered. Unfortunately, React and its cousins all have to deal with the idiosyncracies of the legacy browser environment. You have CSS, which applies and cascades styles to elements and their children in often non-obvious ways, and is a monster to deal with on any given day.

In addition to CSS, you have multiple potential sources of state. Every HTML slider, dropdown, input field, accordion, radio button, checkbox has its own browser-native state. You have to control for that.

On top of all of this, the browser application is usually just a frontend client that has to interact with a backend server, with asynchronous calls that require wait-state and failure-state management.

One thing that's in common with all of the above problems is: they're localized. All of these things I'm describing are specific to the rendering layer and therefore the component layer; they are not related to central state. A central state trying to capture all of these problems will fail, because component state has to be wrangled locally near where the HTML is; CSS also is component-level; and the network states are often very closely related to each component. If we maintain a central "game state", the data complexity just proliferates endlessly for each instance of the component.

So, the default these days is to keep state very close to each component, including network state, and often business logic also gets sucked into the mix. I try to avoid putting business logic in components, but people do it all the time unfortunately. But it does add to the complexity.

In other words, there is -real- complexity here, stemming from the fact that the web was never built to be a distribution+execution layer for rich applications, but evolved to become exactly that. It's not just bad application architecture or bad decisions by React maintainers.

Maybe I'm wrong, since I'm not a game developer and don't see what you're seeing on your side.

[applfanboysbgon]

I'm sympathetic to "it's the browser's fault", to some degree. I understand that the browser locks you into certain constraints, and I understand that I don't understand much about those constraints, because most of the extent of my experience with web development is using a canvas and a couple of fundamental APIs to render my games via WASM as web is one of my build targets (and I do know that approach is undesirable for regular web pages). I can see how there might be unavoidable complexity there.

What I still don't understand is why the browser is that way in the first place, and why all of the native, not-browser GUI frameworks that people use are also that way. People opt into using React Native, even! But the regular run-of-the-mill frameworks that are widely used for native applications are also annoyingly complex to work with, so much so that I've repurposed my engine for when I want to create native applications and have been working on building a desktop UI framework within it that follows the same model I use for games (albeit nowhere near production-grade, just covering "the cases I need").

> the browser application is usually just a frontend client that has to interact with a backend server

I will note that this is a constraint that is shared with gamedev. Most multiplayer and even many singleplayer games these days are server-based.