42 ms·

Yeah, I cannot count how many times I've seen it claimed that the virtual DOM is the secret to why React(or another framework) is fast, completely missing the p

Yeah, I cannot count how many times I've seen it claimed that the virtual DOM is the secret to why React(or another framework) is fast, completely missing the point of the virtual DOM. The virtual DOM is not faster than performing direct mutations of the actual DOM, the virtual DOM is a tool that allows the normally slow approach of "blow away and rebuild the world" to be fast enough to put into use.

throwaway11460 3y ago
Virtual DOM used to be faster than DOM. DOM operations were really slow back when React came out, and the usual componentization approach of replacing entire blocks of code with new HTML strings used to lock up the browser. React made it possible to effortlessly reuse previous state DOM nodes.
- Osmose 3y ago
  Your second statement that the virtual DOM lets you skip unnecessary DOM mutations is true, but the first statement is inaccurate because "DOM" is not equivalent to "regenerate and replace all the DOM nodes with updated ones". Prior to React, performant apps that weren't using frameworks that regenerated the entire DOM tree would simply manually mutate the DOM nodes based on what it was doing. If your app was loading a new comment, it would find the list of comment nodes and append a new one to it, same as a virtual DOM would. The problem is that this could be error-prone in large apps—are you even sure that the comment list is still on the page? If it's not, do you need to add it to the page or is this a completely new view and you're reacting to a network request that finished after the user navigated away from the page? That's the kind of finnicky manual work that React helped simplify, but the performance was the same as an app manually mutating the DOM plus the extra virtual DOM comparisons.
  - throwaway11460 3y ago
    The usual approach used to be to simply replace entire "component" with updated HTML string returned by a function representing that component. Doing what you're saying was not feasible for large apps, that led to unmaintanable spaghetti code and never really worked correctly - imagine you need to add a feature somewhere and then you have to go into all the other components that rely on that internal structure. I am talking about CRMs and other business apps like that, not some light JS to load blog comments.
    - acdha 3y ago
      None of what you’re saying is globally true. It might have been true of the apps you personally worked on but it’s not the case that everyone did HTML string replacement or that using the DOM directly forced you to forget basic software engineering concepts.
      - throwaway11460 3y ago
        It's what was commonly done across more than 10 companies in Europe over a decade I worked in the field. Looking back at the source code of projects back then, it was the normal method.
        acdha 3y ago
        So say that rather than pretending to speak for the entire web.
        throwaway11460 3y ago
        I said that. It's faster than the browser DOM operations. Replacing a block of DOM is a DOM operation too.
        acdha 3y ago
        It was faster in the early 2000s. It hasn’t been for the last decade and a half - try it now and be reminded just how bad IE6 was: https://www.quirksmode.org/dom/innerhtml.html https://www.quirksmode.org/dom/innerhtml.html https://segdeha.com/experiments/innerhtml/ https://segdeha.com/experiments/innerhtml/ The thing which was slow is changing more than you need to change. When the React marketing push included performance, that’s almost always what they were comparing it to - someone would have slow code making the same updates multiple times or triggering reflows by forcing the browser to do a partial update to measure something, and then updating again. There’s an argument that the guaranteed overhead of using React is better because it helps the average developer who doesn’t measure performance much do a better job than they might have otherwise, and that can be true for many people but it also tended to get oversimplified to “React is fast” despite widespread evidence to the contrary.

throwaway11460 3y ago

Virtual DOM used to be faster than DOM. DOM operations were really slow back when React came out, and the usual componentization approach of replacing entire blocks of code with new HTML strings used to lock up the browser. React made it possible to effortlessly reuse previous state DOM nodes.

Osmose 3y ago
Your second statement that the virtual DOM lets you skip unnecessary DOM mutations is true, but the first statement is inaccurate because "DOM" is not equivalent to "regenerate and replace all the DOM nodes with updated ones". Prior to React, performant apps that weren't using frameworks that regenerated the entire DOM tree would simply manually mutate the DOM nodes based on what it was doing. If your app was loading a new comment, it would find the list of comment nodes and append a new one to it, same as a virtual DOM would. The problem is that this could be error-prone in large apps—are you even sure that the comment list is still on the page? If it's not, do you need to add it to the page or is this a completely new view and you're reacting to a network request that finished after the user navigated away from the page? That's the kind of finnicky manual work that React helped simplify, but the performance was the same as an app manually mutating the DOM plus the extra virtual DOM comparisons.
- throwaway11460 3y ago
  The usual approach used to be to simply replace entire "component" with updated HTML string returned by a function representing that component. Doing what you're saying was not feasible for large apps, that led to unmaintanable spaghetti code and never really worked correctly - imagine you need to add a feature somewhere and then you have to go into all the other components that rely on that internal structure. I am talking about CRMs and other business apps like that, not some light JS to load blog comments.
  - acdha 3y ago
    None of what you’re saying is globally true. It might have been true of the apps you personally worked on but it’s not the case that everyone did HTML string replacement or that using the DOM directly forced you to forget basic software engineering concepts.
    - throwaway11460 3y ago
      It's what was commonly done across more than 10 companies in Europe over a decade I worked in the field. Looking back at the source code of projects back then, it was the normal method.
      - acdha 3y ago
        So say that rather than pretending to speak for the entire web.
        throwaway11460 3y ago
        I said that. It's faster than the browser DOM operations. Replacing a block of DOM is a DOM operation too.
        acdha 3y ago
        It was faster in the early 2000s. It hasn’t been for the last decade and a half - try it now and be reminded just how bad IE6 was: https://www.quirksmode.org/dom/innerhtml.html https://www.quirksmode.org/dom/innerhtml.html https://segdeha.com/experiments/innerhtml/ https://segdeha.com/experiments/innerhtml/ The thing which was slow is changing more than you need to change. When the React marketing push included performance, that’s almost always what they were comparing it to - someone would have slow code making the same updates multiple times or triggering reflows by forcing the browser to do a partial update to measure something, and then updating again. There’s an argument that the guaranteed overhead of using React is better because it helps the average developer who doesn’t measure performance much do a better job than they might have otherwise, and that can be true for many people but it also tended to get oversimplified to “React is fast” despite widespread evidence to the contrary.