The dom-diffing style makes me think of one of my beliefs about software. You have two styles.
An active style where where when state is updated side effects happen directly inside the same call graph.
And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future.
The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.
The first style is the source of uncountable UI bugs. I have lost track of the number of times I’ve seen the developer forget to set a dirty bit to redraw the screen when some state changes. It’s the imperative vs. declarative model. Declarative may often be slower but it has other strengths.
Don't get me wrong. I totally understand that your way is why we don't see annoying rendering bugs anymore. We just put up with UI's that are slower than 25 year old UI's on machines that are a 100 times faster.
At least with web apps, that tends to be the “Redux” style more than the “React” style causing that. Basically, lazy state management (and I mean this pathologically rather than in terms of Haskell’s ‘lazy’). The laziness comes from the business side of things, squeezing more productivity out of engineers per dollar. The declarative style doesn’t slow down web apps very much, it’s rerendering every component any time a state changes anywhere that does.
On mobile it’s a trade off of rendering bugs with UI bugs. I’ve seen issues on older Android phones where Compose causes the text field to lose focus and flicker when typing if autocomplete is switched on. The workaround is to tell users to switch it off in the OS settings. And of course the latency issues are UX concerns all their own
An active style where where when state is updated side effects happen directly inside the same call graph.
And this passive disconnected spooky action at a distance where you update state and something else is supposed to/might execute side effects at some unspecified time in the future.
The first way there is no magic going on. The second way it's all magic. I try to avoid writing code the second way if at all possible.