5 ms·

> 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 cl

> 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.
  - aidenn0 5y ago
    > React code was simple enough that it wasn't hard to understand and trace trough, or profile Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through. > That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.
- Quinner 5y ago
  It's hard to say for certain, but it sounds as if you may have been doing things that caused lots unnecessary re-renders. React has some pitfalls for beginners, but I've built highly complex frequently updating webapps without the degree of slowness you're speaking of.
- rasz 5y ago
  Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736 https://news.ycombinator.com/item?id=27449736
  - runawaybottle 5y ago
    I just read that and chuckled. Someone must have been under pressure and just said fuck it, this works.
darepublic 5y ago
no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read too much damn code where a dev wants to do something straightforward but either because of ignorance or some cultural pressure reaches for a complicated library way to do it, finds that said library doesn't solve the problem well, and then misuses that library or exploits one of its escape hatches in the solving of the problem just to say that their code used the new shiny library. As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.
- catlifeonmars 5y ago
  > but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo. I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.
  - megous 5y ago
    Adding and removing nodes from a tree doesn't require a phd. I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.
- imbnwa 5y ago
  > As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo. As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.
zozbot234 5y ago
> 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 "Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.

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.
- aidenn0 5y ago
  > React code was simple enough that it wasn't hard to understand and trace trough, or profile Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through. > That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.
Quinner 5y ago
It's hard to say for certain, but it sounds as if you may have been doing things that caused lots unnecessary re-renders. React has some pitfalls for beginners, but I've built highly complex frequently updating webapps without the degree of slowness you're speaking of.
rasz 5y ago
Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736 https://news.ycombinator.com/item?id=27449736
- runawaybottle 5y ago
  I just read that and chuckled. Someone must have been under pressure and just said fuck it, this works.

darepublic 5y ago

no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read too much damn code where a dev wants to do something straightforward but either because of ignorance or some cultural pressure reaches for a complicated library way to do it, finds that said library doesn't solve the problem well, and then misuses that library or exploits one of its escape hatches in the solving of the problem just to say that their code used the new shiny library. As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

catlifeonmars 5y ago
> but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo. I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.
- megous 5y ago
  Adding and removing nodes from a tree doesn't require a phd. I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.
imbnwa 5y ago
> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo. As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.

zozbot234 5y ago

> 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 "Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.