4 ms·

Can anybody offer a friendly explanation to me as to why it's not wise to update the DOM directly? I understand that React is supposed to be an efficient and "

Can anybody offer a friendly explanation to me as to why it's not wise to update the DOM directly? I understand that React is supposed to be an efficient and "ergonomic" way to develop for the increasingly complex array of devices out there in the world, but I have had too many poor experiences with React to consider it better than direct UI programming for my needs.

grzm 6y ago
One of the motivations for using a virtual DOM as opposed to updating the DOM directly is that DOM updates can be slow, with a minimum duration per change. Applying changes to a virtual DOM can be faster for individual changes, and then those changes can be batch-applied to the actual DOM, minimizing the number of changes to the DOM itself. For larger client applications this can be a win. Like all trade offs, the choice depends on the context.
- sushshshsh 6y ago
  Neato, so then much like an enterprise service bus (ew old term), there is a bus that comes at a rate of x hertz that events can be loaded onto, and the bus has a certain capacity for events. The busses then load events from the event queue and when it reaches the client, they're all rendered at once. Sounds cool. I guess this is what all of the componentDidMount and componentWillMount is used for?
- ric2b 6y ago
  If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. What V-DOM is trying to address is tracking what is changing in your application so that it can modify the DOM on your behalf, simplifying app development and reducing bugs, sort of like how a Garbage Collector manages memory for you and gives you similar benefits. Look at Svelte, it doesn't have a V-DOM and it smokes any V-DOM framework in terms of performance.
  - littlecranky67 6y ago
    > If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. It uses a very smart algorithm to diff two vDOMs (previously rendered vs. newly rendered) and "calculates" a minimal* set of operations required to get the current DOM (=prev. rendered vDOM) into the new state of the DOM (=result from current vDOM render). Think in source code patches produced by tools like diff: A patch between two different code tree versions can fit just a few lines and is quickly applied against the tree, while shipping and writing the full tree is more expensive. *: ideally it would be minimal in a sense there is no smaller/faster representation, but thats of course not the case in real applications.
slig 6y ago
You'd have to write the code to apply the state to the DOM. React abstracts that in a very optimized way.
pier25 6y ago
It's perfectly fine to update the DOM yourself. The problem is really that hand writing the vanilla code to do that will be tedious to say the least. Svelte is essentially that. You write simple components. The compiler checks the dependency graph and converts your code into the vanilla code that would be needed to render those components and make the necessary changes when you modify a reactive variable. That's why Svelte apps are much faster and smaller. You also write a fraction of the code compared to React/Vue/etc which I think it's actually the best part about Svelte.
- ric2b 6y ago
  I was drawn to Svelte by the performance/bundle size but I fell in love with how simple it is to write components and share data between them. Each component is just HTML/CSS/JS in a single file, sort of like Vue but cleaner. If you're curious I recommend either the "rethinking reactivity" talk from the author: https://youtu.be/AdNJ3fydeao https://youtu.be/AdNJ3fydeao or the tutorial: https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics Both are great!
  - pier25 6y ago
    > Each component is just HTML/CSS/JS in a single file, sort of like Vue but cleaner. A lot cleaner!
deleted 6y ago
[deleted]
kansface 6y ago
> Can anybody offer a friendly explanation to me as to why it's not wise to update the DOM directly? Sure! The fundamental problem that React solves is turning some canonical notion of state into the DOM (with an eye on composability). This is the central problem of web dev. Once your application grows large enough, you will inevitably end up re-implementing a much worse, ad-hoc solution out of $ or innerHTML. You will build your own React and will be responsible for maintaining it! If the scope of your app is small any solution OK. I'm speaking from experience: I have built several Reacts over a decade or so - so before it existing and a few afterwards.

grzm 6y ago

One of the motivations for using a virtual DOM as opposed to updating the DOM directly is that DOM updates can be slow, with a minimum duration per change. Applying changes to a virtual DOM can be faster for individual changes, and then those changes can be batch-applied to the actual DOM, minimizing the number of changes to the DOM itself. For larger client applications this can be a win. Like all trade offs, the choice depends on the context.

sushshshsh 6y ago
Neato, so then much like an enterprise service bus (ew old term), there is a bus that comes at a rate of x hertz that events can be loaded onto, and the bus has a certain capacity for events. The busses then load events from the event queue and when it reaches the client, they're all rendered at once. Sounds cool. I guess this is what all of the componentDidMount and componentWillMount is used for?
ric2b 6y ago
If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. What V-DOM is trying to address is tracking what is changing in your application so that it can modify the DOM on your behalf, simplifying app development and reducing bugs, sort of like how a Garbage Collector manages memory for you and gives you similar benefits. Look at Svelte, it doesn't have a V-DOM and it smokes any V-DOM framework in terms of performance.
- littlecranky67 6y ago
  > If that were true how would virtual DOM ever be faster than the DOM? It would still have to update the DOM itself. It uses a very smart algorithm to diff two vDOMs (previously rendered vs. newly rendered) and "calculates" a minimal* set of operations required to get the current DOM (=prev. rendered vDOM) into the new state of the DOM (=result from current vDOM render). Think in source code patches produced by tools like diff: A patch between two different code tree versions can fit just a few lines and is quickly applied against the tree, while shipping and writing the full tree is more expensive. *: ideally it would be minimal in a sense there is no smaller/faster representation, but thats of course not the case in real applications.

slig 6y ago

You'd have to write the code to apply the state to the DOM. React abstracts that in a very optimized way.

pier25 6y ago

It's perfectly fine to update the DOM yourself. The problem is really that hand writing the vanilla code to do that will be tedious to say the least. Svelte is essentially that. You write simple components. The compiler checks the dependency graph and converts your code into the vanilla code that would be needed to render those components and make the necessary changes when you modify a reactive variable. That's why Svelte apps are much faster and smaller. You also write a fraction of the code compared to React/Vue/etc which I think it's actually the best part about Svelte.

ric2b 6y ago
I was drawn to Svelte by the performance/bundle size but I fell in love with how simple it is to write components and share data between them. Each component is just HTML/CSS/JS in a single file, sort of like Vue but cleaner. If you're curious I recommend either the "rethinking reactivity" talk from the author: https://youtu.be/AdNJ3fydeao https://youtu.be/AdNJ3fydeao or the tutorial: https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics Both are great!
- pier25 6y ago
  > Each component is just HTML/CSS/JS in a single file, sort of like Vue but cleaner. A lot cleaner!

deleted 6y ago

[deleted]

kansface 6y ago

> Can anybody offer a friendly explanation to me as to why it's not wise to update the DOM directly? Sure! The fundamental problem that React solves is turning some canonical notion of state into the DOM (with an eye on composability). This is the central problem of web dev. Once your application grows large enough, you will inevitably end up re-implementing a much worse, ad-hoc solution out of $ or innerHTML. You will build your own React and will be responsible for maintaining it! If the scope of your app is small any solution OK. I'm speaking from experience: I have built several Reacts over a decade or so - so before it existing and a few afterwards.