Hacker News new | comments | show | ask | jobs | submit login
Demystifying React's Virtual DOM (medium.com)
19 points by gzeus 33 days ago | hide | past | web | favorite | 11 comments



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


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.


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


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.


UX/UI != code quality.


Having myself not worked with React, I think it’s a more common pattern than you think to re-render/rebuild an entire section of a page to reflect small model updates. It’s a less error prone but less efficient way of maintaining consistency. Virtual DOM exists to help make that exact sort of thing more efficient.


Virtual DOM is an abstraction that provides reasonable performance for less effort. You can always get more performance by bypassing the abstraction, but at the cost of more work and complexity.


Writing straight to the DOM is pretty fast - faster than a high-speed internet connection. It's the core idea behind a side project - write webpages in JSON, and have a small Javascript engine add these to the DOM.

It still has some bugs, but when it works, it's faster than calling the server for each page. This is because the entire site is loaded into the browser, and each page is deleted and rebuilt when a link is clicked. https://www.sparational.com


Well, obviously it's always faster if a developer carefully crafts the minimal possible DOM changes by hand, than letting an automatic system to decide on it - but updating one label isn't a very realistic situation. Usually one will need to do a dozen of changes at once all over the page, and for maintainability (and keeping the sanity) reasons devs usually do it in some sort of batch operations. And that's where react, vue, angular, etc. have proven to be superior approach for anything but simplest apps.


Actually not true - browsers already batch DOM change repaints.


*remystifying




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: