What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".

React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.

This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.

That is a ”controlled component” model which is bad for interactivity, especially text inputs.

If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.

Without a rerender, it must now use a reactive binding to update the field value.

If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.

Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.

Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.

"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)

Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.

Then computers got faster, much much faster. It became possible to redraw the whole UI from state every frame without it being a significant cost.

At the same time retained user interfaces managed to become more and more costly to do just about anything. I don't think for any particular reason other than computers were fast and they didn't need to do much better.

I find it really odd that there are user interfaces that take longer to rearrange their items than it takes for the same CPU to RayTrace a scene covering the same amount of screen area.

At the very least, I understand why your techniques help you...

[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.

the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.

therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen.

furthermore the typical modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.

This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.

Maybe <canvas> if you clear it on every frame.

>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI

which I interpreted as the only possible meaning, in relation to React, being UI components that must rerender as close to immediately as possible vs. UI components that do not need immediate rerendering when the underlying data has changed.

I realize that is not a particularly correct use of the phrases, but then that is what happens when you use a concept from one type of development metaphorically in another type of development, memetic slippage as it were.

> In immediate mode, the scene (complete object model of the rendering primitives) is retained in the memory space of the client, instead of the graphics library. This implies that in an immediate mode application, the lists of graphical objects to be rendered are kept by the client and are not saved by the graphics library API. The application must re-issue all drawing commands required to describe the entire scene each time a new frame is required, regardless of actual changes.

React is simulating immediate mode by having the developer describe the full rendered result from the current data state. The developer / app code doesn't need to keep track of what changes need to be done to get the browser from its current state to the desired state, React does that for you.

Retained mode is where the developer / app does have to concern itself with the current browser state and issue the desired updates themselves, like how everything was done in the jquery era and earlier.

These are requirements the DOM / CSSOM addresses, you'd probably not have an easy time getting this right in a <canvas>.

I did no such thing. In fact I expressed my understanding of why you prefer your methods. I was hoping you would be willing to consider why declarative, composable UI patterns are worthwhile. Instead you substitute a deep topic for "React".

Have a good one, I have no intention of getting into a technical discussion with someone whose first reaction is to jump down people's throats.

"You don't know about X? Well, at least I know about X and Y..." Doesn't seemed like a good faith comment to me either?

And then you say "You misunderstood my intentions so I'm going to disengage". For what it's worth, I didn't interpret your argument as insulting someone, but also it wasn't a useful or productive comment either.

What did you hope to achieve with your comments? Was it simply to state how you know something the other person doesn't? What purpose do you think that serves here?

For my part, I also loathe the insensate writhing mass of frameworks, patterns and dependencies that is "modern" frontend development. Where you and I differ is I recognize a handful of extremely good ideas hidden in the morass. But I am perfectly happy dismissing the majority of it; if nothing else, you shouldn't come away thinking of me as a React fanboy.

Writing is a lossy medium for thought, and programming is no exception. I'd say at a minimum that you and I are on the side of programmers whose code is a medium for their own thought.

All of these choices really just comes down to cognitive bandwidth, context, domain, taste, any number of things, really. Which is what was behind my first (admittedly terse, slightly salty) comment.

What I condemn is someone who opts out of making choices for themselves in their software. Web dev just happens to have an unfortunately high concentration of this sort of thoughtlessness.

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.

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

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

This bottleneck could be alleviated if browsers shipped native dom morphing or even some kind of native vdom but we're stuck with userland js solutions.

I can't really think of a statement that resonates with me less.

To an extent this is how react works internally. There is a function which takes state and produces UI. In order not to have to re-render the whole UI if only a small part of the state changes, there is a diffing algorithm and "virtual dom" that is diffed against. Maybe it doesn't work exactly like that anymore but that's the gist of it.