Comment by Mev-Rael on "The one thing that no one properly explains about React — Why Virtual DOM"

Have seen this "explanation" and diagram many times. But still, useless and actually doesn't explain everything.

When a Virtual DOM wants to what you call "rerender", it needs to use native DOM API itself because otherwise it is just impossible to communicate with the browser. Why I need a lot of extra layers here when I can do just A -> E instead of A -> B -> C -> D -> E with document.createDocumentFragment() for example?
When exactly a browser is doing "rerendering"? What about "forced reflow", "read first and write second"? Why you think modern browsers are not doing a lot of optimization already.
Any real business code examples where everyone can compare good vanilla JS DOM manipulation and same code with Virtual DOM? Please no more useless innerHTML in the loop. I've been loading and rerendering 10000+ comments with plain JS easily.
Any benchmarks?

These simple questions in normal situations developer can answer quickly, however in this "virtual" problem even core author of React couldn't answer any of them.

DOM isn't slow, you are - korynunn.wordpress.com/2013/03/19/the-dom-isnt-sl…

A complex SPA would involve a bunch of DOM changes whenever you perform an action on the UI, batching all of them together as one, and then sending it to the DOM, to reduce the browser computations (as explained in the story) is Virtual DOM’s USP.
Of course, if you’re only having a single node change mapped to all possible actions in your UI, you are indeed adding more layers; and the concept of a Virtual DOM is useless. As far as benchmarking is concerned; you can validate this fact with the following benchmarking tool: https://localvoid.github.io/uibench/ As an instance, you can see the sort operations, (which generally involve “more” DOM manipulations) are faster by a factor of at least 2x (The benchmark I’ve performed was VanillaJS vs React)
The benefit of createDocumentFragment() is visible when you are appending new nodes to the DOM; but a general SPA use case calls not for adding new nodes to the DOM, but manipulating the ones that are already present in the DOM tree. If you say you would use it to dump the changes then you would have to write your own reconciler to know what old content to remove, to be replaced by this new fragment.
It is not that the browsers are already doing a lot of optimisation; they are, whenever a reflow/repaint happens the browsers already optimise for it. Read the “How Browsers Work” document linked in the story for the specifics. But the fact that every DOM manipulation is followed by all the steps and calculations given above; along with the fact that you don't have to keep track of which piece requested what modification, is what calls for the need of a Virtual DOM.
Lastly, Virtual DOM is just a cherry on the React cake. What makes React (not VirtualDOM, but React) prominent is this neat idea on how you would go about having your UI as a function of your data, that is brought together with the concepts of unidirectional data flow, and composition of your UI parts through components.

Hope this helps. Since you say you're "loading and rerendering 10000+ comments with plain JS easily" (you meant components?), may I know how exactly are you doing this; is this a part of app you are building? If yes, how about performing a benchmark on this, and a React alternative. That would be cool.

I understand the idea of vDOM. Any app today has changes in the UI but you don't need to for that to remove original body/section and place a modified body/section instead all the time. With vDOM you have a bit of less UI computations, but you now have new computations - you need to store in memory a huge document and each time search in it for changes. After that when vDOM will render into DOM browser still will do it job, you can't avoid it.
Can you provide a specification for sorting use case - What do you have, what do you want to do and what results are you expecting? I will write a vanilla JS sorting example and then we can compare. It's hard for me to browse so many .ts files to find what exactly it is doing :) In any case in real world you will never have so many operations at the same time and 2) screen size is very limitted, you don't need to do anything with 100 posts above I already scrolled, only when I can see changes +- some space, only then UI needs to change.
As a developer I always know what exactly must be changed, when and where. Yes createDocumentFragment() does the job when you add nodes but when you modify... I again need real examples of these complicated SPAs to be able to answer this. For each use case there is a simple solution. What exactly must be done? ...and it's not sorting a huge table every 10ms on my screen. Avarage human reaction is about 300ms. No more then one click per 300ms, no more then one action per 300ms.
What you call a React's idea to separate app into components is noway related and invented by React. It is a common and general way in software architecture and it was for many many years. It's hard to say who was first, but we can be sure that this idea is at least 25 years old since it is one of the core concepts in what is called a UNIX Philosophy. In frontend we actually had these components at least for 10 years of jQuery where each jQuery plugin or a subset from jQuery UI library - is a component. Talking about the data every app today inherits from 3-tier architecture (MVC ot MVwhatever) and again it is a very old principle and not connected to React. Every software has separation of business logic and presentation logic. User clicks on button, calls for action, XHR made, server reads DB, returns data, client puts this data in DOM. It always was unidirectional and Angular's 2-way data binding just blowed up the Internet with another buzzword and useless technic. In my vanilla apps I have a very small window.Api object after that I have a models directory with small ajax/API-speaking objects composed with window.Api and my usual vanilla reflow looks like:
```
// like a comment
btn.addEventListener('click', () => {
const commentId = btn.dataset.id;
// waiting for AJAX response, if there will be errors 
// PostComment based on Api object will show a small alert
PostComment.like(commentId).then(() => {
  // and if everything is ok, here we are doing our rerendering,
  // it's up to PostCommentUI object how to do that, 
  // in this case it could be just 
  // 1) incrementing .textContent (and NEVER InnerHTML) in some <span> where like count is stored
  // 2) mark a like button as active, something like btn.classList.add('active'), that's all
  PostCommentUI.like(commentId) 
});
});
```

you need to store in memory a huge document and each time search in it for changes.

It's not true, because it do not store whole VDOM in memory forever. On each render (setState() call) it make lightweight DOM representation and efficiently compare it with real DOM. Then after render garbage collector remove VDOM from memory.

The main profit in VDOM: it do efficient DOM patches. Second profit is scheduling DOM updates. First DOM render will be slow as innerHTML.

Why you think modern browsers are not doing a lot of optimization already.

We have legacy and mobile browsers that can't do work effectively.

Of course it stores the VDOM in memory. What would it compare against when it does a rerender?

The virtual dom will always be slower than manual dom updates. Just try making a list of 10,000 items and appending to the list. The virtual dom will have to do an expensive diff each time only to see that one element has changed. In the end it will call the same appendChild method that you would of called in Vanilla JS. A few times I've had to bail out of the virtual dom because it was just too slow.

The virtual dom is about making things easier for developers. It is not faster and it doesn't unleash some magical API that only the virtual DOM can access. If you don't believe me React core developers have said the same thing. Namely that doing what the virtual dom does in vanilla js will always be faster.

Batching updates doesn't make it faster either. Browsers wait for all tasks and microtasks to finish before rendering the next frame. So even if the virtual dom does dom updates all at once and you do it in vanilla JS mixed in with your business logic, it wont make a difference unless you are using certain properties and methods that trigger a reflow. If you use fragments you can beat the virtual dom every time.

Search Hashnode