5 ms·

I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state.

I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely. The mental model is so easy to work with. There is a sleep-management routine to save on CPU usage when idle, and dirty logic to avoid re-drawing static content constantly. I feel like the world would save 90% of its GUI development time if it didn't do whatever the fuck reactive UIs are doing.

hliyan 7mo ago
That reminded me of another complexity: virtual DOM diff.
croes 7mo ago
UI is mostly static. Rendering everything at framerate per second is a huge waste of time and energy.
- Lerc 7mo ago
  This was the case back in the days of the Amiga and 68000 Macs. Rendering everything every frame was impossible, the only way to make it work at all was to draw only what was absolutely necessary to depict changes. 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.
  - croes 7mo ago
    Just because computer got much faster doesn’t mean it’s a good idea to make wasteful rerenderings of things that didn’t change.
    - Lerc 7mo ago
      No but calculation becoming more efficient than recall might not make it a good idea to make wasteful fetches.
      - croes 7mo ago
        Nothing id more effective than doing nothing.
mpalmer 7mo ago
[flagged]
- applfanboysbgon 7mo ago
  Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo. [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.
  - mpalmer 7mo ago
    [flagged]
    - applfanboysbgon 7mo ago
      I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.
      - mpalmer 7mo ago
        To be perfectly fair, you accused me of insulting you and said you "loathe" a word which I thought was a fairly inert term of art. Would you believe I didn't actually notice that you wanted me to say more? :) More than happy to give the benefit of the doubt though, the shoe's been on the other foot for me more than once. 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.
whstl 7mo ago
> The master Render() function draws all of the graphics according to the current state 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.
- cluckindan 7mo ago
  >components should be simple and not store data in themselves. 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.
  - deleted 7mo ago
    [deleted]
  - Izkata 7mo ago
    I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed. 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.
deleted 7mo ago
[deleted]
chill1234 7mo ago
Isn't that what reactive ui trying to achieve? To only have a render function and have ui state sync according to the data?
- incrudible 7mo ago
  Games do not sync data, they literally say what should be drawn on the screen, from scratch, 60+ times per second. They are in control of the entire process. They do not need to deal with DOM manipulation overhead because there is no DOM.
  - chill1234 7mo ago
    Yes, in web to always draw from scratch, it would be slow, therefore exists reactive UI, so people can program like drawing from scratch but less slow.
scoopdewoop 7mo ago
That is immediate-mode graphics. Fine when you are already power-budgeted for 60 frames each second. UIs typically use retained-mode graphics, with persisting regions.
cjonas 7mo ago
This is basically "reactive UI" foundation. The complexities come from effects (now managed via hooks)
monarchwadia 7mo ago
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 7mo ago
  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.
pier25 7mo ago
Games can afford the luxury to re-render everyting on every frame. The DOM? Not so much. 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.
tmanderson 7mo ago
lol this is why so many game UIs are awful (how much they lack in terms of OS accessibility, keyboard controls/shortcuts, etc)
potsandpans 7mo ago
> I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forwar I can't really think of a statement that resonates with me less.
wonnage 7mo ago
Congrats, you described imgui which is basically react
sureglymop 7mo ago
This made me immediately think of the Elm architecture. 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.

hliyan 7mo ago

That reminded me of another complexity: virtual DOM diff.

croes 7mo ago

UI is mostly static. Rendering everything at framerate per second is a huge waste of time and energy.

Lerc 7mo ago
This was the case back in the days of the Amiga and 68000 Macs. Rendering everything every frame was impossible, the only way to make it work at all was to draw only what was absolutely necessary to depict changes. 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.
- croes 7mo ago
  Just because computer got much faster doesn’t mean it’s a good idea to make wasteful rerenderings of things that didn’t change.
  - Lerc 7mo ago
    No but calculation becoming more efficient than recall might not make it a good idea to make wasteful fetches.
    - croes 7mo ago
      Nothing id more effective than doing nothing.

mpalmer 7mo ago

[flagged]

applfanboysbgon 7mo ago
Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo. [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.
- mpalmer 7mo ago
  [flagged]
  - applfanboysbgon 7mo ago
    I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.
    - mpalmer 7mo ago
      To be perfectly fair, you accused me of insulting you and said you "loathe" a word which I thought was a fairly inert term of art. Would you believe I didn't actually notice that you wanted me to say more? :) More than happy to give the benefit of the doubt though, the shoe's been on the other foot for me more than once. 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.

whstl 7mo ago

> The master Render() function draws all of the graphics according to the current state 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.

cluckindan 7mo ago
>components should be simple and not store data in themselves. 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.
- deleted 7mo ago
  [deleted]
- Izkata 7mo ago
  I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed. 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.

deleted 7mo ago

[deleted]

chill1234 7mo ago

Isn't that what reactive ui trying to achieve? To only have a render function and have ui state sync according to the data?

incrudible 7mo ago
Games do not sync data, they literally say what should be drawn on the screen, from scratch, 60+ times per second. They are in control of the entire process. They do not need to deal with DOM manipulation overhead because there is no DOM.
- chill1234 7mo ago
  Yes, in web to always draw from scratch, it would be slow, therefore exists reactive UI, so people can program like drawing from scratch but less slow.

scoopdewoop 7mo ago

That is immediate-mode graphics. Fine when you are already power-budgeted for 60 frames each second. UIs typically use retained-mode graphics, with persisting regions.

cjonas 7mo ago

This is basically "reactive UI" foundation. The complexities come from effects (now managed via hooks)

monarchwadia 7mo ago

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

pier25 7mo ago

Games can afford the luxury to re-render everyting on every frame. The DOM? Not so much. 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.

tmanderson 7mo ago

lol this is why so many game UIs are awful (how much they lack in terms of OS accessibility, keyboard controls/shortcuts, etc)

potsandpans 7mo ago

> I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forwar I can't really think of a statement that resonates with me less.

wonnage 7mo ago

Congrats, you described imgui which is basically react

sureglymop 7mo ago

This made me immediately think of the Elm architecture. 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.