3 ms·
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 s
by ironmagma 3y ago
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.
- Gibbon1 3y agoDon'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.
- h0l0cube 3y agoOn 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
- ironmagma 3y agoAt 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.