Demystifying React's Virtual DOM

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.

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.

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

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