Virtual DOM is pure overhead (2018)

Post by kevingadd » Mon, May 20, 2019, 11:12 PM UTC

Sawamara wrote: post #324

kevingadd wrote: post #278

Earlier quoted context omitted.

You overestimate the cost of modern DOM operations. It's a battle between your virtual DOM (to optimize DOM operations without lots of diffing overhead) and the native DOM (which is frequently a bunch of JS that can get inlined and avoid duplicate work)

No I do not. You will have to work very hard to back up the claim that modern DOM operations are not costly. Plenty of lookups can cause repaint or reflow. Scenario A: (Vdom-like approach) - Render x with dimensions x,y,z,w. - Store the reference to the created DOM elements. - Store dimensions it was created with If you do not go towards this way, and actually query DOM-land to get the dimensions you need to check ag…

Post by dmix » Mon, May 20, 2019, 11:46 PM UTC

tylerhou wrote: post #125

dmix wrote: post #86

Earlier quoted context omitted.

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 solutio…

> 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 ? The trick is if you know the height/w…

Post by chriswarbo » Tue, May 21, 2019, 9:04 AM UTC

onion2k wrote: post #147

jasonkester wrote: post #119

Earlier quoted context omitted.

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You hav…

Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working w…

    $(function(){
      var myState = 123;
      var myElem  = $('' + myState + '');
      $('#myParent').append(
        myElem,
        $('').click(function(){
          myState = myState + 1;
          myElem.text(myState + '');
        }));
    });

Post by jkoudys » Tue, May 21, 2019, 2:48 PM UTC

oraphalous wrote: post #54

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…

Post by mellab2 » Thu, May 23, 2019, 12:56 PM UTC

jondubois wrote: post #313

mellab2 wrote: post #149

Earlier quoted context omitted.

Sorry but what complexity are you talking about? React (particularly in the early days) has always had a comparatively small API surface. You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell. I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - pe…

>> I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things. I disagree with this. Everyone claims that you can use React without JSX but no one does it. Aside from ugliness, the main reason why no ones does this is because you would be missing the most use…