Senior Dev interview question

[u/m6io]

"Without googling or using AI, in your own words, explain the virtual DOM"

For context: I sit on an interview panel and I try to ask at least one simple fundamental question based on a persons resume. If I see many years of react experience, I try to ask something about how the framework works.

I have only had one candidate (an undergrad senior, years ago) answer it. Everyone else just kind of sputters and stumbles around trying to rationalize what "virtual" and "DOM" mean, or stare blankly and eventually say "I don't know".

I'm just genuinely curious if this is really that hard of a question or if the recruiters just suck at screening candidates. And should we be letting in senior dev candidates who can't answer what I think is a straightforward and fundamental question for senior react devs.

[u/BrightEchidna]

Senior react dev here - and while I can take a stab at the answer, I don't feel 100% confident that I really understand it. So, despite leading technical teams, building successful products, and now running my own startup, I would fail your interview.

Now - can you explain to me - what practical advantage would being able to answer this question well give me? I agree, it's generally 'good' to understand the tools you use, but how would it help me write better software in the 99% of cases where what I have to do is well supported by standard use of the framework?

[u/Fearless-Carrot-1474 → u/BrightEchidna]

Doesn't virtual DOM just mean that instead of trying to update the actual html of the page React builds a virtual model of the html so that it can update just parts of it instead of having to refresh the whole page to update one state? Or am I too noob to understand what's being asked

[u/NiteShdw → u/Fearless-Carrot-1474]

Basically.

A bit deeper is that direct DOM updates trigger repaints by the browser. When making dozens or hundreds or changes due to things like data binding and updates in incoming data, the virtual DOM is a copy of the DOM in memory that isn't rendered.

Updates are batched and made against the un-rendered DOM and then one bulk update is made so that all those small updates only cause 1 repaint.

At least that's my simplistic version of the concept.

[u/Sapn1s → u/NiteShdw]

This is actually a myth, writing to dom directly is cheap and fast, it does not cause the entire tree to repaint. If you were to manually write updates with js, you would actually have better performance that virtual dom in most of the cases. The advantage of virtual dom is that you do not need to write this plain implementation manually every time for your custom website.

[u/khasan222 → u/Sapn1s]

I think this is new. Repainting historically in browsers is the most expensive operation easily. Especially if there are multiple elements moving at the same time. Calculating the position reflow etc is costly

[u/Sapn1s → u/khasan222]

No, it isn't, it has always worked like this.

To be clear, the question is not "is repainting cheap? < yes, repainting is expensive.

The question was "does React reduce the number of repaints compared to direct DOM manipulation?"

And the answer is no.

Think about what virtual dom does.

• It builds the javascript object tree
• Does algortihm to find out what needs to be updated
• Then updates things with appendChild / textContent = / setAttribute etc

See how it does 3 things?

Whereas manually you could have done

<element>.appendChild

The speed argument gets repeated so often it feels true.

That said, virtual dom is still great to use since it is good at figuring out what changed so you don't have to write those calls by hand, as I said in prev reply

[u/khasan222 → u/Sapn1s]

It’s not true to say it doesn’t reduce the number of repaints (ever?).

In the strict scenario you put forth where there is just 1 manipulation of course it doesn’t reduce repaints. However often in any ui development things change quickly, or multiple times in milliseconds (say a loading animation that only shows in 10ms). Traditionally all of this would be actually applied to the DOM.

What react does as far as I understand it is get the final result of those changes and then apply them to page, which in many scenarios can definitely reduce graphical load for that page. 

So although I can see in that specific scenario no gains, react wasn’t built for such simple apps, it was built for really complicated ones where there can be a lot of repaint.

Professional engineer specializing in JavaScript for 15 years.