5 ms·

> In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case,

> In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation. In my experience, the exact opposite occurs. If there is ever any heavy computation I need to do, I usually try spawn a web worker or offload it to the server. In contrast, as your app tree grows reconciliation costs grow (super?)linearly, and more importantly there is (currently) no way to offload reconciliation.

dmix 7y ago
Same, the only time I've run into performance issues with Vue after building many very complex deeply nested components prior to this was one which ground to a halt on re-rendering because I was simply rendering too many elements into the DOM with their subsequent watchers filling up memory. After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solution was to paginate the particular content. 99% of the users never had this issue but it was 1-2 customers who had thousands of components to render instead of the usual hundreds. I'm really curious now if Svelte would have helped with that because it was a huge dev timesink and one where I was never satisfied with the solution. As it really should be able to render that amount of data. It obviously wasn't a problem in the jQuery/Rails version I was replacing and improving upon (although page load times was higher). The new React concurrency model wouldn't have helped from what I've read. I just needed something lighter weight from the rendering model itself. Vue 3.0 is apparently going to come with plenty of performance improvements so I'm looking forward to that as well.
- tylerhou 7y ago
  > After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solution was to paginate the particular content. 99% of the users never had this issue but it was 1-2 customers who had thousands of components to render instead of the usual hundreds. Did you try something like https://github.com/Akryum/vue-virtual-scroller https://github.com/Akryum/vue-virtual-scroller? The trick is if you know the height/width of the elements, you can only render the elements directly in the viewport (+ some padding) and replace the missing elements with fixed-size blank divs, whose width and height you can find with some math. That way, you don't have to rely on the browser to layout your elements, nor do you have to reconcile hidden elements. (Essentially, element occlusion culling for the virtual DOM.) Looks like vue-virtual-scroller only works with fixed-height elements (because n * m is easier to compute than n_1 + ... + n_m), but as long as you don't rely on the browser for layout the same trick works with preknown variable element sizes.
  - dmix 7y ago
    That wouldn't have worked for the problem unfortunately. It was a pretty compact UI with a lot going on so scrolls wouldn't have masked enough components. Thanks for the link though.
- PudgePacket 7y ago
  You could use svelte just for that heavy component and see if it makes a difference? Svelte compiled output is very small (only brings what you need) so you can quite easily embed it without dragging along a whole extra framework.
  - dmix 7y ago
    Eh, I'm already mixing enough JS libraries moving to Vue from jQuery, plus all the other frontend garbage that built up over the years. This would have to be the next major product or iteration I work on. But I will be trying Svelte out on my side projects which is typically how I evaluate new stuff. Never at work :p
spoiler 7y ago
Product/application growth doesn't necessarily mean the DOM grows, though.

dmix 7y ago

Same, the only time I've run into performance issues with Vue after building many very complex deeply nested components prior to this was one which ground to a halt on re-rendering because I was simply rendering too many elements into the DOM with their subsequent watchers filling up memory. After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solution was to paginate the particular content. 99% of the users never had this issue but it was 1-2 customers who had thousands of components to render instead of the usual hundreds. I'm really curious now if Svelte would have helped with that because it was a huge dev timesink and one where I was never satisfied with the solution. As it really should be able to render that amount of data. It obviously wasn't a problem in the jQuery/Rails version I was replacing and improving upon (although page load times was higher). The new React concurrency model wouldn't have helped from what I've read. I just needed something lighter weight from the rendering model itself. Vue 3.0 is apparently going to come with plenty of performance improvements so I'm looking forward to that as well.

tylerhou 7y ago
> After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solution was to paginate the particular content. 99% of the users never had this issue but it was 1-2 customers who had thousands of components to render instead of the usual hundreds. Did you try something like https://github.com/Akryum/vue-virtual-scroller https://github.com/Akryum/vue-virtual-scroller? The trick is if you know the height/width of the elements, you can only render the elements directly in the viewport (+ some padding) and replace the missing elements with fixed-size blank divs, whose width and height you can find with some math. That way, you don't have to rely on the browser to layout your elements, nor do you have to reconcile hidden elements. (Essentially, element occlusion culling for the virtual DOM.) Looks like vue-virtual-scroller only works with fixed-height elements (because n * m is easier to compute than n_1 + ... + n_m), but as long as you don't rely on the browser for layout the same trick works with preknown variable element sizes.
- dmix 7y ago
  That wouldn't have worked for the problem unfortunately. It was a pretty compact UI with a lot going on so scrolls wouldn't have masked enough components. Thanks for the link though.
PudgePacket 7y ago
You could use svelte just for that heavy component and see if it makes a difference? Svelte compiled output is very small (only brings what you need) so you can quite easily embed it without dragging along a whole extra framework.
- dmix 7y ago
  Eh, I'm already mixing enough JS libraries moving to Vue from jQuery, plus all the other frontend garbage that built up over the years. This would have to be the next major product or iteration I work on. But I will be trying Svelte out on my side projects which is typically how I evaluate new stuff. Never at work :p

spoiler 7y ago

Product/application growth doesn't necessarily mean the DOM grows, though.