In this article, we will examine the dom in detail and what the virtual dom is.
What is the DOM (Document Objec Model) ?
When a web ...
For further actions, you may consider blocking this person and/or reporting abuse
Ya. "Modern" libraries are moving away from Virtual DOM because when you're doing SSR on server side, this just slows down the entire process and make the application unnecessarily heavy and bloated making developer experience worse. When you're sending only partial components with SSR, calculating such complex DOMs becomes overkill. That's why strategies like Svelte or SvelteKit gained popularity because compilers knows how to render that Component and does it even needs to be executed ahead of time and can it be cached etc. While Virtual DOM has to be memoized. React team is switching to a hybrid compiler model but they can't go full compiler like Svelte and Solid does because of library complexity.
You are right, I will explain srr and csr in another article
The virtual DOM is based on the misconception that it is not possible to know in advance which state changes will lead to what DOM changes.
Nearly all modern frameworks but React are now based on signals, which bind state changes directly to render effects.
You should have mentioned that the structure of the virtual dom tree is different from the browser dom tree. Since virtual dom tree has nodes for Component, Fragment, Empty (true, false, null...) Context... and browser tree does not. People dont know that, but I guess they dont care
You're right! It's a great point that the virtual DOM tree has a different structure, with nodes for Components, Fragments, Empty values, and Context, unlike the browser DOM.
Well there are going to be a few corrections:
This is primarily because web browsers are optimized to process strings that we call HTML, and also, the entire processing and node creation part is handled by native code, so it's observably faster than manual creation.
VDOM was not really created because of perceived slowness of .innerHTML, rather it hints to a limitation of the web, where we can clearly see that the browser don't diff the nodes itself for some reason. Also it was considered faster before signal architecture became popular.
Ultimately, any imperative javascript code will outperform frameworks any day. (Ofcourse given that it's well written)
Hi Mayyukh,
1-This maybe true, but I did not say otherwise in this article.
2- in this article, I did not say that vdom was created because innetHtml is slow. what I want to analyze is : "VDOM usually works faster than manual DOM manipulations done directly with JavaScript to change something in the browser. This is because VDOM calculates changes to a virtual DOM structure using a diff algorithm and applies only the necessary updates to the real DOM. "
Read this section again
We now know that the easiest way to change the dom ("Change HTML") is to change the innerHTML property in an element. This method of modifying html does not performance well in DOM repainting (" Updating what the user sees ").This is because innerHTML needs to parse DOM nodes from a string, preprocess, and append it. if there are too many html mutations on a web page, there will be a performance issue.
3- Performance and code writing/editing are different concepts. frameworks and libraries provide developers with ease of writing code, reusability, and performance optimization with technologies such as VDOM. For example, libraries such as React make it easier for developers to write more sustainable and readable code.
It may be useful to examine the term "JSX" at this point. JSX allows you to use an HTML-like syntax within JavaScript code and makes it easier to define and edit components in libraries such as React. JSX is compiled into JavaScript and interacts with VDOM, efficiently updating user interfaces. you can also explore the concepts of server side rendering and client side rendering
Virtual dom is used only in react or other api
react.js , vue.js ,preact, etc.
Most frameworks now move away from virtual dom, and can perform way better than react.
The virtual DOM (VDOM) is a performance-boosting mechanism used by frameworks like React to optimize updates in the actual DOM. By creating a lightweight copy of the real DOM, the VDOM reduces the number of direct DOM manipulations, which are known to be slow. Here's how it works and some alternatives that can potentially offer even better efficiency:
How the Virtual DOM Improves Performance
Alternatives to the Virtual DOM
Reactive DOM (e.g., Svelte): Svelte doesn’t use a virtual DOM. Instead, it compiles components to direct JavaScript code at build time, updating the real DOM instantly based on state changes. This often results in faster performance than the VDOM because it avoids the diffing and VDOM re-rendering process.
Incremental DOM (e.g., Google’s Lit): Incremental DOM updates only specific parts of the DOM that have changed, without needing a virtual DOM tree. This can be more memory-efficient and is beneficial for lightweight applications with simpler UI components.
Fine-grained Reactivity (e.g., Solid.js): Fine-grained reactivity, as seen in Solid.js, directly links state to specific parts of the DOM. This avoids the need for a VDOM by updating only what’s necessary, allowing for faster, more granular updates, especially in interactive applications.
Direct DOM Manipulation (Vanilla JavaScript or jQuery): Direct manipulation is suitable for simpler applications with few state changes. While efficient for straightforward UIs, it can become challenging and less performant in state-heavy applications due to the lack of controlled rendering.
Are These Alternatives More Efficient?
In some scenarios, these alternatives can indeed be more efficient than the virtual DOM:
However, the virtual DOM remains effective for complex applications with frequent updates and nested structures. Choosing the best approach depends on the application’s complexity and performance needs, as each method has its strengths for different use cases.
Which one did you use to "write" this answer: chatgpt, copilot, google, claude..? 🙄
Nice explanation on why many frameworks and libraries uses virtual DOM. Thanks! Keep the good content.