4 ms·

Performance characteristics are that this increases expsense with the size of your data where as just re-rendering increases expense with the size of your UI. I

by jesstaa 11y ago

Performance characteristics are that this increases expsense with the size of your data where as just re-rendering increases expense with the size of your UI. It's actually much more common to have lots of data but only render a small amount of it, so re-rendering is generally cheaper. The size and complexity of UIs have a natural limit because of screen size and usability, but the amount of data you use to generate a UI has essentially no natural upper limit. Pete Hunt gave a talk on exactly this almost two years ago. https://www.youtube.com/watch?v=-DX3vJiqxm4 https://www.youtube.com/watch?v=-DX3vJiqxm4

ikido 11y ago
That's a good point, but in Redux you subscribe to all changes in single state tree where all data lives. That means that every update of data (which has no upper limit) will cause your UI to re-render. Sure, you can implement shouldComponentUpdate, but still it will be called on every state update, plus you do can do exactly the same with mobx. The difference is that with mobx you subscribe to changes of certain data, and it happens automatically.
- jesstaa 11y ago
  The talk addresses this. The whole point of Reactjs is that updating the whole UI isn't very expensive so you don't have to worry about doing fine grained data change tracking (which is harder to optimise due it not scaling well as data sizes increase)
  - monfera 11y ago
    I'll assume a render tree with only functional components for simplicity's sake, and no observables, just plain function application: A full rerendering requires that all the functions be called. Indeed, there's a natural limit to how much data is updated on the screen (well, unless we use canvas or WebGL but I digress) but the render functions themselves may be expensive and wasteful to rerun, especially if there is inferrable knowledge that the nature of the change doesn't warrant a recalc in some branches. Even if it doesn't cause jitter, it may be wasteful on mobile battery. Why do I think render functions may be expensive? Official React documentation steers people toward having stores that keep 'primary truths' rather than things that can be derived from them via pure functions; and it suggests that these calculations be part of the render functions. It works, it's functional and it's clean. But you potentially run a lot of calculations, depending on the domain. With plain FP, much of this will be wasted as causing no visible change. Not only this, but the needlessly executed render functions do generate virtual DOM snippets; and these snippets do get scheduled for DOM diffing. All these add up to what is, in my experience, a jank-inducing difference. I even introduced memoization, but just DOM diffing alone is significant on a sizeable app (which makes sense as there may be an order or two magnitude difference between VDOM elements that exist vs. ones that really may change). With observables, e.g. reexecuting a calc or regenerating a DOM snippet, control is finer grained, without the manual and possibly erroneous performance optimization hinting approach known as shouldComponentUpdate. I had cases when blind function reapplication (memoized or not) caused jank on the desktop while observables were smooth even on the mobile.
mweststrate 11y ago
Sure, the promise of VDoms is performance. And vDOM has improved DOM performance a lot. But also not nearly enough to support the complexity of most real life applications that handle a decent amount of data (say, 1000 visible components at the same time). That is the reason why frameworks based on immutability and PureRenderMixin (such as Redux) were able to gain popularity in React in the first place. They solved largely this performance issue (and not vDOM in itself) Just scan through my blog https://www.mendix.com/tech-blog/making-react-reactive-pursuit-high-performing-easily-maintainable-react-apps/ https://www.mendix.com/tech-blog/making-react-reactive-pursu... to see how naively fully re-rendering your application upon each change makes your application an order of magnitude(!) slower. Data size isn't usually an issue for MobX. The reason for that is that it will automatically suspend all derivations which are not actively in use somewhere (in other words, not visible currently in the screen). We have full blown visual editors that have hunderd thousands observables in memory. Nonetheless they are fast enough to perform drag and drop actions using observables, where not only the dragged item is being moved, but also all the connectors connected to it, as they observe the item being dragged.

by jesstaa 11y ago

ikido 11y ago

That's a good point, but in Redux you subscribe to all changes in single state tree where all data lives. That means that every update of data (which has no upper limit) will cause your UI to re-render. Sure, you can implement shouldComponentUpdate, but still it will be called on every state update, plus you do can do exactly the same with mobx. The difference is that with mobx you subscribe to changes of certain data, and it happens automatically.

jesstaa 11y ago
The talk addresses this. The whole point of Reactjs is that updating the whole UI isn't very expensive so you don't have to worry about doing fine grained data change tracking (which is harder to optimise due it not scaling well as data sizes increase)
- monfera 11y ago
  I'll assume a render tree with only functional components for simplicity's sake, and no observables, just plain function application: A full rerendering requires that all the functions be called. Indeed, there's a natural limit to how much data is updated on the screen (well, unless we use canvas or WebGL but I digress) but the render functions themselves may be expensive and wasteful to rerun, especially if there is inferrable knowledge that the nature of the change doesn't warrant a recalc in some branches. Even if it doesn't cause jitter, it may be wasteful on mobile battery. Why do I think render functions may be expensive? Official React documentation steers people toward having stores that keep 'primary truths' rather than things that can be derived from them via pure functions; and it suggests that these calculations be part of the render functions. It works, it's functional and it's clean. But you potentially run a lot of calculations, depending on the domain. With plain FP, much of this will be wasted as causing no visible change. Not only this, but the needlessly executed render functions do generate virtual DOM snippets; and these snippets do get scheduled for DOM diffing. All these add up to what is, in my experience, a jank-inducing difference. I even introduced memoization, but just DOM diffing alone is significant on a sizeable app (which makes sense as there may be an order or two magnitude difference between VDOM elements that exist vs. ones that really may change). With observables, e.g. reexecuting a calc or regenerating a DOM snippet, control is finer grained, without the manual and possibly erroneous performance optimization hinting approach known as shouldComponentUpdate. I had cases when blind function reapplication (memoized or not) caused jank on the desktop while observables were smooth even on the mobile.

mweststrate 11y ago

Sure, the promise of VDoms is performance. And vDOM has improved DOM performance a lot. But also not nearly enough to support the complexity of most real life applications that handle a decent amount of data (say, 1000 visible components at the same time). That is the reason why frameworks based on immutability and PureRenderMixin (such as Redux) were able to gain popularity in React in the first place. They solved largely this performance issue (and not vDOM in itself) Just scan through my blog https://www.mendix.com/tech-blog/making-react-reactive-pursuit-high-performing-easily-maintainable-react-apps/ https://www.mendix.com/tech-blog/making-react-reactive-pursu... to see how naively fully re-rendering your application upon each change makes your application an order of magnitude(!) slower. Data size isn't usually an issue for MobX. The reason for that is that it will automatically suspend all derivations which are not actively in use somewhere (in other words, not visible currently in the screen). We have full blown visual editors that have hunderd thousands observables in memory. Nonetheless they are fast enough to perform drag and drop actions using observables, where not only the dragged item is being moved, but also all the connectors connected to it, as they observe the item being dragged.