We Keep Coding

How Virtual DOM works in React or Vue

I m a student and I m trying to create own Virtual DOM for my college project ( It will not have any advanced feature like props or events, I will keep it simple ) in JavaScript like other famous frameworks React, Vue and other.
I just want to know that when we have multiple file of code( code splitting ). If I make a change in any deep child than do I need to compare complete virtual DOM (including all child and parent element) or I just need to compare only that child elements.
If I have to compare complete new virtual DOM ( including all children ) with previous Virtual DOM. Then Why should I care re-rendering in React or Vue ( because any changes in child will force the framework to compare complete Virtual DOM )

For Vue,
The working of virtual DOM differs in vue2 and vue3.
The way vue3 does it, is,
By parsing the HTML template or render function from the component files and converting it to a Virtual Node representation.
While doing the parsing, it records the nodes that have a dependency on dynamic data.
Something like below
dynamicData = {
data1: [ effect1, effect2, ... ],
data2: [ effect4, effect5, ... ],
... }
Effects are functions that define computations required to resolve certain data values.
Effects also include render function for the Virtual nodes
Render functions smartly converts virtual nodes to DOM elements
Now whenever data1 changes Vue3 re-executes the corresponding effects and triggers update for subsequent data changes.
References:
Vue3 Reactivity
Vnode Transformation

Answer to your last point as I infer from my experience of React is that comparing Virtual DOM's in Javascript is the thing that helps react know what things it has to re-render on the actual DOM, So the "re-rendering" is the hard part on which the performance of the APP takes the hit. Hopefully, this would help.

Is My Understanding of React Reconciliation Correct?

From what I've scraped together by looking through different tutorials all day, it seems like the way that react performs updates to the dom is through the following process.
User interacts with the real DOM in some way that triggers a DOM event, and the event's handler ends up fires a function that tells react to update.
React takes a "snapshot" of the virtual dom (which is also representative of the real dom at this point), and then proceeds to create a new virtual dom with the updated state and props.
React diffs the snapshot and the new virtual dom, and then only modifies parts of the dom that need to be modified to match the new virtual dom.
Is my understanding of this process correct, at least at a simplistic level?

It's almost correct, I think the mistake here is that there is no "new virtual DOM", React
always saves/uses/reuses two copies - VDOM representations of the real DOM.
(A) VDOM which helps to make changes to the real DOM (according to this VDOM, React will make the minimal changes to the DOM).
(B) VDOM which represents all changes made to real DOM (what you called a "snapshot", this VDOM will be compared to A).
So to summary the process like you did:
If VDOM does not exist, create one (VDOM A).
User interacts with the real DOM in some way that triggers a DOM event, and the event's handler ends up fires a function that tells react to update.
React creates (or reuses) one of the VDOMs (B) (which is also representative of the real dom at this point).
React diffs VDOM B with VDOM A, and then only modifies parts of the VDOM (A) that need to be modified.
React updates the real DOM using VDOM A.
Note for part 3. React uses the diff algorithm, which is somewhat just comparing the element's keys and props (shallow comparison).

How exactly is React's Virtual DOM faster?

I understand that there are two arguments for React's Virtual DOM being faster -
It updates ONLY those elements that actually need to be updated (using diff).
It batches the updates and hence we update the real DOM only a single time. Thus the repainting is also done only once which otherwise would have been done multiple times.
I have questions regarding both these points -
As far as I know, all the modern browsers are efficient enough to update only the required elements in the DOM. For example, if I have two 'p' tags and I change the text in one of the p tags using a button click, then only that p tag will be updated by safari (I have verified this using paint flashing). So how is point 1 an advantage if it is already being implemented by the browsers?
How exactly does React batch the updates? Eventually React will also have to use the DOM api to update the real DOM. So why is that if we directly use the DOM api then the changes will not be batched whereas when React uses it then they are batched?

I have found the answer to my question.
The key is to understand the purpose of the Virtual DOM.
First we have to see what approach React takes to render the components.
Different javascript frameworks take different approaches to detect changes in the data model and render them on the view.
Consider AngularJS. When we refer to our data in an Angular template, for example in an expression like {{foo.x}}, Angular not only renders that data but also creates a watcher for that particular value. Whenever anything happens in our app (click event, HTTP response, timeout), all the watchers are run. If the value in a watcher has changed then that value is re-rendered in the UI. By running all the watchers AngularJS is essentially finding out where it needs to make the changes. The process of running these watchers is called dirty checking.
React takes a different approach. Whenever there is a state change in a React component, instead of finding out where to make the changes (like AngularJS), React re-renders the entire UI from scratch (with the updated state).
But this approach of React has a problem. To re-render the entire UI means to re-render the entire DOM tree. This is a problem because DOM updation is a slow process (due to reflow and repainting).
This is where React's Virtual DOM comes in. A Virtual DOM is just a representation of the Real DOM in form of javascript objects. It is just a tree data structure of plain javascript objects that exists in the memory. As compared to the Real DOM, rendering of the Virtual DOM is much faster because it is never rendered on the screen (no reflow or repainting needs to be done).
So how does the Virtual DOM solve the problem? When we load our app, React creates a Virtual DOM that is an exact virtual copy of the Real DOM. Whenever there is a state change in a component, instead of re-rendering the entire Real DOM, React renders an entire new Virtual DOM (with the updated state). Then it does a diff between the old Virtual DOM (the initial copy of the Real DOM) and this new Virtual DOM (rendered after state change) to find out the changes between them and it does ONLY those changes in the Real DOM. In this way, the entire UI is re-rendered (by rendering an entire new Virtual DOM) but only the minimum required changes are done in the Real DOM.
So when it is said that "Using Virtual DOM React updates only those elements that need to be updated" (point 1 in my question), it means that with the help of Virtual DOM React is overcoming the limitations of its own approach (approach of rendering the entire UI from scratch).
This answer also explains the same concept.
I have seen some answers that state that DOM manipulation using React is faster than using the DOM api because the DOM api re-renders the entire DOM tree whereas React re-renders only those parts of the DOM tree that need to be changed. This is NOT true. All modern browsers are efficient enough to update only those parts of the DOM tree that need to be changed. This can be verified using paint flashing in developer tools of browsers (also see this answer and this answer). Even if we assume that the DOM api does re-render the entire DOM tree, still this reasoning is false because the internal code of React itself has to use the DOM api to update the DOM. If the DOM api did re-render the entire DOM tree then React would also re-render the entire DOM tree because eventually it also uses the DOM api to update the DOM.
As for the second point, React actually makes batching easier for us.
In React, while the reads are done on the Real DOM, the writes (state changes) are not done on the Real DOM. Instead the writes are queued. Then when all our reads and writes have been processed, a new Virtual DOM is built based on the writes. Then diffing is done between the old and new Virtual DOM and then React writes the required changes to the Real DOM to update it. Hence eventually all the writes on the Real DOM are done together in a single reflow.
But we can manually also, without React, write our code in such a way that first all reads are done and then all writes are done. React makes batching easier because with React we don't have to care about doing the reads and writes together and React will automatically batch the writes for us. So React does not make things fast. It makes things easier.
In conclusion we can say that React is not actually faster. It is easier. As Pete Hunt says in this video, "React is not magic. Just like you can drop into assembler with C and beat the C compiler, you can drop into raw DOM operations and DOM API calls and beat React if you wanted to. However, using C or Java or JavaScript is an order of magnitude performance improvement because you don't have to worry...about the specifics of the platform. With React you can build applications without even thinking about performance and the default state is fast.".
This post by Rich Harris also states that it is a myth that "the Virtual DOM is fast".

Once React knows which virtual DOM objects have changed, then React updates only those objects, in the real DOM. This makes the performance far better when compared to manipulating the real DOM directly. This makes React standout as a high performance JavaScript library.
Regarding the Batch Update:
React follows a batch update mechanism to update the real DOM. Hence, leading to increased performance. This means that updates to the real DOM are sent in batches, instead of sending updates for every single change in state.
The repainting of the UI is the most expensive part, and React efficiently ensures that the real DOM receives only batched updates to repaint the UI.

Isn't React's immutable element creation and rendering mechanism terribly inefficient?

I am not a React developer, but I am implementing a similar State and Props management infrastructure in another language. While reading about React's state management and rendering mechanism, I came across this quote
React elements are immutable. Once you create an element, you can’t change its children or attributes. An element is like a single frame in a movie: it represents the UI at a certain point in time.
If I understand correctly, every time the parent component's state changes, its children's render methods are called (if their Props was affected) and these child components are recreated and (re)rendered.
Isn't this terribly inefficient, especially if the child components involve complex computations, visualizations, etc? Is there a mechanism in React to create the components once, but update (not recreate) only the necessary parts as the states change?

Well, that's the whole point of why we use React.
Have you heard about Virtual DOM? Virtual DOM is simply a memory instance that saves the exact replica of the real DOM.
When there is a prop/state update, it does not re-render the whole thing, but only re-renders the UI parts that are affected.
So, it's very efficient and to see how they do it, you can check the source code here.

smallest example on how virtual DOM is efficient

i have been reading many articles over this.
as per my understanding, virtual DOM is simple javascript object representation of real DOM.
whenever some state change happens, new Virtual DOm object is created and compared with old one using diff algorithm in o(n) time and updates the browser only the changed parts.
my question is , why didn't browsers do this themselves.?
also i tried checking differences between vanilla and react by using simple key press inside a text field using chrome devtools.
vanilla js and react have following traces under Main have following steps.
event: key press //both have
event: textInput //both have
recalcualte style// both have
Layout// only vanilla js has, React version doesn't have this step ??
update layer tree// both have
Paint.//both have
my question for above observation is why react version doesn't have layout step which is taking 0.48 ms in vanilla.
is this what causes react to be faster.
i also learned about layout thrashing and batch updates. as we don't interact with browser using DOM manipulation directly in React, batch update logic is undertaken by React. is this why react is efficient? so any new web developer needn't worry about effiecnt ways of updating browser(say like avoiding reflow/layout thrashing) instead focus on developing actual features and react does all for us?
it would be helpful if you can provide very basic demo example where virtual DOM has real advantage, i will use chrome devtools do the investigation myself. thanks :)