alt Hacker NewsI 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.
Replies
Isn't that what reactive ui trying to achieve? To only have a render function and have ui state sync according to the data?
This is basically "reactive UI" foundation. The complexities come from effects (now managed via hooks)
That reminded me of another complexity: virtual DOM diff.
UI is mostly static. Rendering everything at framerate per second is a huge waste of time and energy.
> 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.
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.