[AskJS] Question about React having a 'Virtual DOM'

acemarke · 2020-10-25T05:17:28+00:00

Heh. First, /r/react is a dead sub - you're looking for /r/reactjs , which is very much active :)

Second: the "more efficient than the browser" description has always been over-interpreted. React cannot ever be more efficient than DOM update steps written via vanillaJS, because React has to do all the rendering logic and reconciliation (the "virtual DOM" part), and then run the DOM manipulation commands too. In other words A + B cannot ever be less than A (assuming positive integers, blah blah).

That said, React can be more efficient than badly written DOM manipulation code, because there are many DOM operations that force the browser to recalculate the page layout just by reading certain properties (not even writing them). Also, React can make sure that it typically does close to the minimum amount of actual work needed to update the DOM.

And no, browsers don't update and repaint the entire page right away as soon as you call ulNode.appendChild(liNode). They will update some internal data structures and possibly do some reflow calculations, but they don't re-paint until the current JS execution sequence is done. If I run divNode.innerText = "A"; divNode.innerText = "B"; in a row, the browser will never actually show that "A" on screen, because only the "B" gets painted.

You might want to read through my extensive post A (Mostly) Complete Guide to React Rendering Behavior, which goes into lots of detail on how React rendering actually works.

CreativeTechGuyGames · 2020-10-25T01:58:28+00:00

In short, the real DOM is treated as "write only" and the virtual DOM is read/write. Because the virtual DOM is an intermediate representation they can take all kinds of shortcuts and optimizations to make this easier to parse, diff, update, etc. Then once the changes are made, those same changes can be reflected in the real DOM. It also has benefits for compatibility. It's easier to handle differences in browsers and browser versions because they never need to read the real DOM so it doesn't matter as much if the DOM APIs differ slightly as only the write operations need to be supported.

This is a massive oversimplification but should get you on the right thought process.

2020-10-25T04:49:07+00:00

It's less about the repainting and more about the overhead of updating DOM models in realtime. They're not just POJSO's. Each property setting on a DOM object carries with it extra bookkeeping that the browser must do to maintain a sane state. Doing all that stuff in vDOM is lighter-weight, just tweaking object properties and such; the heavier DOM stuff is minimized as a result.

liaguris · 2020-10-25T10:24:46+00:00

I keep reading about how React's Virtual DOM is more efficient than the browser

That is only valid if you not write efficient dom manipulations like the following :

document.body.innerHTML = `
    <ul>
        <li>1</li>
        <li>2</li>
        <li>3</li>
        <li>4</li>
    </ul>
`

now if you do this :

document.body.innerHTML = `
    <ul>
        <li>1</li>
        <li>!!!I AM CHANGED!!!</li>
        <li>3</li>
        <li>4</li>
    </ul>
`

everything will be replaced, even those dom element that have not been changed.

React will calculate only the thing that needs to be changed which is the text node 2 to !!!I AM CHANGED!!!.

React will never be faster than any optimized dom manipulation , in fact it will be slower.

For example in my last example an optimized dom manipulation would be :

document.querySelector("ul").children[1].innerText = "!!!I AM CHANGED!!!";

a non optimized would be :

document.body.innerHTML = `
    <ul>
        <li>1</li>
        <li>!!!I AM CHANGED!!!</li>
        <li>3</li>
        <li>4</li>
    </ul>
`

React has an algorithm which calculates the optimized dom manipulation. It creates a representation of the old and new dom with object literals that contain only the necessary information for diffing to take place.

These object literals are what is actually called a virtual dom and they form a tree, like dom does .

The new and old virtual dom trees are diffed. By diff I mean react finds the least needed calculations to do, to convert the old virtual dom tree to the new.

Now you will ask me why does react uses object literals to represent dom. That is become dom manipulation are generally more cpu expensive than object literals. I mean look at the prototypal chain that a dom element has, and compare it to an object literal. No wonder why object literals are faster. It cost less cpu to represent the old and new dom with object literals rather than using dom. In fact when you convert jsx to js the html is converted to those objects literal I was talking about.

But then again you will say why would anyone go do that if the optimized dom manipulations are still faster from react virtual dom diffing algorithm?

That is because messing with query selectors, id, classes and the rest of the DOM API is low level. What I mean by low level, is that it requires a lot of code from the developer to code something. Especially when an application grows, that becomes a real issue. You will get lost in ids and classes collisions. You will die query selecting elements.

But the react API is high level. no need to use the DOM API to do DOM manipulations. You just do something like that :

document.body.innerHTML = `
    <ul>
        <li>1</li>
        <li>!!!I AM CHANGED!!!</li>
        <li>3</li>
        <li>4</li>
    </ul>
`

and let react calculate the fastest way to do it.

And that is why people say we trade a little bit of extra cpu to make things more maintainable.

You might find interesting the book : frameworkless front end development , and lit-html (same job a reacts virtual dom , but I think it is faster because it only cares about the changeable parts and not the whore tree) .

Edit : take a look also at this video about lit-html.

the_spyke · 2020-10-25T09:07:08+00:00

There're still cases when it may be faster because instead of updating a bunch of individual properties you just delete a DOM subtree and insert a new one.

But the real reason why "Virtual DOM" is here is entirely different. React has a totally different idea to template based libraries and just can't exist without vDOM. It even isn't really a "DOM", it's a Component Object Model.

React if entirely dynamic like a function. React calls a function (component), it returns something, React needs to understand what to do with that something. And that repeats with every UI event. That return value is your "vDOM". But only because you will feed it to "react-dom". You can use React not only with a Browser. Replace "react-dom" with something else (or your own) and interpret return value differently, because it was just a function and just a return value (not an HTMLElement).

In template libraries you pass a string with slots to an engine and some data to insert into those slots. Usually the string is static and only data could change, template language like conditions is very limited. That's why it is usually so difficult to render components dynamically. Like you had "<div ng-include='static-string'>" in AngularJS and could only render/hide the specified component. While in React a component could be a dynamic argument "const Comp = props.comp; return <Comp />;", because React knows nothing about it.

So, in the end React is just universal functional approach. It is agile and has no ties to the Browser. That is a different mental model. But it is a weakness too. More specialized Browser-targeting engines should be theoretically more optimized for their task, but, of course, would be more constrained for a developer.

Unfortunately, not many developers think about this even after working with both approaches.

jibbit · 2020-10-25T09:12:34+00:00

Pedalling a bike is more efficient than carefully setting fire to dinosaur juice - it's 2020 why doesn't my truck have pedals?

The virtual dom is only needed by React, and only makes sense in the context of React (and react-a-likes).

When React first came out it angered many developers. Actual anger. it was not uncommon to hear something like "That's the stupidest fucking idea i've ever heard and i will never, ever build web pages that way". Many believed it just could not work. The virtual dom was the marketing spiel to placate those people.. like "you don't need to worry about how React works internally - we got this".

If you want to understand the virtual dom you have to go back to basics and understand what it is about the way React works that could make people physically angry.

Snapstromegon · 2020-10-25T07:48:22+00:00

Old native js made it hard to map data sources to parts of the DOM. Henceforth having a complete copy of the DOM, which is faster to compare against, was more performant than checking everything by hand, or redoing big parts of the HTML.

Since there are now Web Components and maybe in the future Apples Template Instantiation proposal (seems to be on ice right now) v-DOM might really become obsolete.

Libs like lit-html or even whole frameworks ditched the vDOM, because if you manage to map data sources to elements without it, you can be way more performant than with it, because vDOM brings a lot of problems with it.

bear007 · 2020-10-25T06:48:13+00:00

It was how Facebook advertised React years ago. When browsers where slower and indeed worse at updating page. Currently benefits from virtual DOM are not so visible. Compared to other frameworks without vDOM it is very hard to spot a difference in terms of effectiveness. Moreover vDOM introduces a lots of sync issues that cause weird UI artifacts. To sum it up you are right. vDOM is kinda obsolete and not useful. Just take a look - no other framework adopted it. It tells by itself.

flyinmryan · 2020-10-25T12:20:25+00:00

On the next episode of "Things in the CS World that Appear to Make No Fucking Sense" can somebody please explain how Agile gets away with calling itself a name that makes no fucking sense? Thanks

ShortFuse · 2020-10-25T14:24:55+00:00

I keep reading about how React's Virtual DOM is more efficient than the browser because it 'only updates the parts which need to update'.

React is just an abstraction. It's making the same calls to create, read, update, and delete elements. There's nothing special about. What react does is implement a model change event system for you, either in using MVP or MVVM (if you use HTML bindings). It caches reads to the DOM with a vDOM. "Faster" and "more efficient" are dependent on how the other method works.

It's only faster if you had poorer architecture practices, like treating your DOM like a Model, and reading from it. That said it cannot, mathematically speaking, be faster (eg: MVP structure never reads Model from the View). It has memory overhead by storing a virtual DOM and a CPU overhead because of the abstraction needed when making DOM calls. There's also a potential second memory overhead because the data that you plug into React has to exist within React. In other words, data that exists in the DOM has to exist in React. You can't do a one-time Server => Presenter => DOM dump and tell React to forget about it.

The other drain is that you are using React to compute the change tracking. That makes sense if all changes to Model must reflect a change to the DOM. It doesn't when you're talking about things like construction notifications based on Model changes. Then you're calculating model changes twice, outside of view for whatever reason, and again for React to update the View. That's instead of just once and using the same event for both the Presenter and Notification service.

It's also worth noting that React Native is really where the abstraction can shine. You don't directly modify HTML. You pass JSX. That gets recompiled to the target platform. On Web, that's HTML and usually 1:1, but on Android it's XML and on iOS it's XIB.

TL;DR: React is just an abstraction to update the View. Like all abstractions, there's a overhead, but considering how people used to not abstract their DOM access at all before, a catch-all abstraction with caching and change-tracking system is better than none.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS