7 ms·

>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Svelte's ma

• ubercore 5y ago
  I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?
  • lhorie 5y ago
    There's some nuance. DOM mutations are still expensive if you interpolate reading and writing operations. The declarative paradigm allows frameworks to batch same-type operations to prevent double repaints. This is the upsell of virtual DOM vs jQuery, but it's not a benefit that is exclusive to virtual DOM. Virtual DOM comes with a different set of trade-offs in terms of needles and haystacks. If you have lots of mutations relative to the size of the DOM, then virtual DOM overhead per mutation is relatively low. But if you're only updating a single element in a very large tree, then you are incurring a lot of overhead per mutation. Another modern confounding factor to be aware of is that some browsers (notably Chrome) have made it so that mutations through the DOM API no longer cause a repaint to block the main thread (which is how every UI system ever should work, really). What this means is that any performance benchmark that uses JS APIs to measure UI responsiveness is going to be problematic (either by not measuring repaints correctly, or by adding a ton of confounding factors by shoving the macrotime queue of setTimeout/friends into the measurement) Also, qualitatively, there's different levels of overhead. A repaint takes in the order of hundreds of milliseconds (i.e. it can be noticeably expensive). DOM API calls are also "expensive", but only in the order of a millisecond or so; you do want to touching the DOM unnecessarily if possible and virtual dom helps avoid silly mistakes like re-querying the DOM on every event like in the `$('.foo').on('mousemove', () => $('.bar'))` anti-pattern. Virtual DOM is "overhead" in the sense that allocating memory for a virtual DOM node is "expensive" (compared to not allocating any memory). But we're in microsecond-per-instance territory at this point. You need large haystacks with very small needles at high frequencies in a slow device to experience human-noticeable performance degradation from virtual DOM object allocation overhead.
  • macspoofing 5y ago
    >I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. Not really. Rendering was always a heavily optimized area. The DOM, by the way, is also an in-memory data-structure, and can also be clever on how it batches draw commands to the hardware (GPU or otherwise). I was always skeptical of the performance benefits of frameworks like React for that reason. The big benefit of UI frameworks (React or Angular) is that it organizes your code into a defined, maintainable pattern. Traditionally JavaScript has been a mess of a programming language so with raw JS/HTML development it was easy to shoot yourself in the face and do the wrong thing. >I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks? That's not true. There is an enormous amount of investment being poured into the entire HTML/JS/CSS stack.
• mumblemumble 5y ago
  > React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations. Because manually managing all those surgical manipulations would quickly become a fiddly, unmaintainable mess. But, if you do it that way, you're asking the browser to do a lot more re-rendering, and that would be costly. I worry that this conversation falls into the same trap that most performance discussions fall into, where we quickly become focused on what things would be like if people had unlimited time to chase the best-case scenario, rather than what things are like for the 99% of us who are just trying to get something that works acceptably by the next deadline.
  • aidenn0 5y ago
    I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone. Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on stuff, some lists that elements can be added/removed to/from), but those sorts of things seem fairly typical. I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.
    • macspoofing 5y ago
      >I wanted to use React because the code was so much cleaner and concise, but it was just way too slow. I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization. Having said that, React isn't bad either. That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. It's been a few years since I did any meaningful React development, but back when I did, React code was simple enough that it wasn't hard to understand and trace trough, or profile. I guess I'm curious, what the bottleneck was.
• cush 5y ago
  > As a general claim, that is a bullshit claim. How so? It improved on JQuery's performance ten-fold which was the "easy" way to webdev at the time.