3 ms·

> …certain properties have an invisible setter, which immediately triggers a "change" event when you assign a new value to it. I’ve hit this with SwiftUI. Isn’

> …certain properties have an invisible setter, which immediately triggers a "change" event when you assign a new value to it. I’ve hit this with SwiftUI. Isn’t this a general problem of the entire “reactive” style of programming? If you have anything that requires a computation step after model changes, you need to gate when you take into account a set of model changes before you kick off your calculations or you end up with this problem of constant updates that kill performance. I don’t do a lot of front end work, but that’s been my experience with this method of programming in general.

esperent 4y ago
Is it a problem with the reactive style in general, or only when you try to connect it to systems not designed with this style in mind?
- munchbunny 4y ago
  If I’m someone who just wants to get an app out the door, then I’d argue that not being able to gracefully bridge to other paradigms when there is a gap in what is available under a reactive pattern is by itself a problem (an ecosystem problem). That’s why I use React. Despite the issues with bridging to non-reactive abstractions, it remains a useful pattern. Others may be more concerned with the applicability of the pattern itself.
  - pygy_ 4y ago
    This is not unlike integrated automatically GC'd and non-GC'd code. The gap can be bridged for granular reactive systems as it can be for React, provided the reactive system is well designed.
jeroenhd 4y ago
You can have reactive programming with batch state updates. For the longest time, most React code used setState to update the entirety of a component's state at once rather than set each property individually and hope the framework batches up changes fast (or you use manual state update limitation logic like debounces). These days, I see a lot of React code having switched to functional components that suffer from rapid state updates, possibly without the authors even knowing. In theory, these state updates shouldn't be a problem as your rendering logic and your state logic should be separate, at most rendering one or two frames wrong if the state updates are inconsistent. Video games have done this for over a decade and every "modern" GUI framework uses a GPU surface to paint its own controls rather than use existing system windowing, so you may as well take a page out of games' book. Sadly, I don't think many frameworks do this stuff right and a lot of time is spend doing unnecessary state recalculations. It's certainly easier to write bug free GUI code through reactive programming, as state conflict bugs now get gracefully handled by the frameworks, but I think because these issues are now no longer clearly visible they also don't get recognised as bugs anymore. I think this is just one of the many ways development has shifted towards developer comfort over user experience; changing a number in a region in memory and redrawing a string doesn't need to go through 50 chained method calls to update application state, but they make life for the devs easier so they're often tolerated. You get more features in return, but I'm not happy with the price we paid for those (mostly useless) features.
- lmeyerov 4y ago
  For Graphistry's GPU UI, we solve via react code for HTML chrome & interactions, and the visual analytics in webgl controlled by rxjs. Beyond rxjs being an overall coordination language, it lets you do thinks like custom schedulers, and so we are overall synced to requestanimationframe. And we still need to be careful on over updating, but at least we now have abstractions for reasoning about it and guiding it.
- unconed 4y ago
  >redrawing a string doesn't need to go through 50 chained method calls to update application state a) If you use memoization properly, and don't put all your state at the tree root, it doesn't. b) In my experience, devs dramatically overestimate how useful such a hand-optimized fast path is, because in a real application, users expect the UI to always be consistent. It's not just about responding to a string change but also potentially the reason you're displaying a string in the first place. And FWIW, Live is actually a lot leaner than React.
unconed 4y ago
It's not a problem if you have one-way data flow because you can batch everything. You never need to preemptively invalidate a cache, you just reevaluate in tree order.

esperent 4y ago

Is it a problem with the reactive style in general, or only when you try to connect it to systems not designed with this style in mind?

munchbunny 4y ago
If I’m someone who just wants to get an app out the door, then I’d argue that not being able to gracefully bridge to other paradigms when there is a gap in what is available under a reactive pattern is by itself a problem (an ecosystem problem). That’s why I use React. Despite the issues with bridging to non-reactive abstractions, it remains a useful pattern. Others may be more concerned with the applicability of the pattern itself.
- pygy_ 4y ago
  This is not unlike integrated automatically GC'd and non-GC'd code. The gap can be bridged for granular reactive systems as it can be for React, provided the reactive system is well designed.

jeroenhd 4y ago

You can have reactive programming with batch state updates. For the longest time, most React code used setState to update the entirety of a component's state at once rather than set each property individually and hope the framework batches up changes fast (or you use manual state update limitation logic like debounces). These days, I see a lot of React code having switched to functional components that suffer from rapid state updates, possibly without the authors even knowing. In theory, these state updates shouldn't be a problem as your rendering logic and your state logic should be separate, at most rendering one or two frames wrong if the state updates are inconsistent. Video games have done this for over a decade and every "modern" GUI framework uses a GPU surface to paint its own controls rather than use existing system windowing, so you may as well take a page out of games' book. Sadly, I don't think many frameworks do this stuff right and a lot of time is spend doing unnecessary state recalculations. It's certainly easier to write bug free GUI code through reactive programming, as state conflict bugs now get gracefully handled by the frameworks, but I think because these issues are now no longer clearly visible they also don't get recognised as bugs anymore. I think this is just one of the many ways development has shifted towards developer comfort over user experience; changing a number in a region in memory and redrawing a string doesn't need to go through 50 chained method calls to update application state, but they make life for the devs easier so they're often tolerated. You get more features in return, but I'm not happy with the price we paid for those (mostly useless) features.

lmeyerov 4y ago
For Graphistry's GPU UI, we solve via react code for HTML chrome & interactions, and the visual analytics in webgl controlled by rxjs. Beyond rxjs being an overall coordination language, it lets you do thinks like custom schedulers, and so we are overall synced to requestanimationframe. And we still need to be careful on over updating, but at least we now have abstractions for reasoning about it and guiding it.
unconed 4y ago
>redrawing a string doesn't need to go through 50 chained method calls to update application state a) If you use memoization properly, and don't put all your state at the tree root, it doesn't. b) In my experience, devs dramatically overestimate how useful such a hand-optimized fast path is, because in a real application, users expect the UI to always be consistent. It's not just about responding to a string change but also potentially the reason you're displaying a string in the first place. And FWIW, Live is actually a lot leaner than React.

unconed 4y ago

It's not a problem if you have one-way data flow because you can batch everything. You never need to preemptively invalidate a cache, you just reevaluate in tree order.