Re:How UI-driven state increases accidental complexity
by dakom on Wednesday March 25, 2020 @02:35AM
(#22682458)
Another angle to consider is that even within the context of UI state, the natural shape of the data may not match the renderer's state.
For example, if you're building a "pong widget" - the UI state is pretty straightforward across the board (paddle position, ball position, etc.) - but that's going to have an "impedance mismatch" when targeting DOM vs. GPU. The former may want things in a left-to-right tree structure[0], the latter may want paddle-meshes first regardless of their position on the screen[1].
Separation of concerns is a wonderful- even essential thing, but can be tricky for large real-world projects.
[0] that's not really a problem here - CSS grid with named areas could solve it in this specific use-case
For example, if you're building a "pong widget" - the UI state is pretty straightforward across the board (paddle position, ball position, etc.) - but that's going to have an "impedance mismatch" when targeting DOM vs. GPU. The former may want things in a left-to-right tree structure[0], the latter may want paddle-meshes first regardless of their position on the screen[1].
Separation of concerns is a wonderful- even essential thing, but can be tricky for large real-world projects.
[0] that's not really a problem here - CSS grid with named areas could solve it in this specific use-case
[1] e.g. to avoid shader switching