
Demystifying React's Virtual DOM - gzeus
https://medium.com/nybles/demystifying-react-s-virtual-dom-eb0f2dc0717a
======
kowdermeister
The article suggests that using virtual DOM you can avoid the 6 steps
described after

    
    
        document.querySelector('#elementId').innerHTML="New Value"
    

But this is not the case, the virtual DOM ensures you that if you have a
complex component it will only update the nodes that actually needs updating,
but the 6 steps still must take place.

[https://reactjs.org/docs/rendering-elements.html#react-
only-...](https://reactjs.org/docs/rendering-elements.html#react-only-updates-
whats-necessary)

------
darepublic
this article is really misleading.. the authors writes as if direct Dom
manipulation is slower than react, then uses a strawman of someone just
changing a huge chunk of the Dom tree at once when only a text label needed to
be changed. no good developer ever does that. reacts selling point is not
blazing speed imo it's good performance (not best) with the plus side of being
easier to write good code.

~~~
Vinnl
> imo it's good performance (not best) with the plus side of being easier to
> write good code.

I would even argue it's the other way around: React's primary selling point is
making it easier to write good (as in: easy to follow) code. That its
performance is very much acceptable is a nice plus or even a requirement, but
would never be the reason for me to choose it.

~~~
amelius
I'm not even sure React helps much in creating cleaner code, because
Facebook's UI, which is written in React, still has many problems.

~~~
tomnipotent
UX/UI != code quality.

------
chadlavi
*remystifying

