How's Virtual DOM implementation is different than createDocumentFragment() if no state is observed?

Question

Virtual DOM is a light weight copy of DOM, maintained / cached locally before inserting it into actual DOM. We can change it as we want and then save to our real DOM tree. It uses efficient diff algorithms to update changes back and forth and other use cases.
This all is done to avoid direct manipulation with DOM as it's an expensive operation.
We have document.createDocumentFragment() method which can be used in JavaScript, which also creates imaginary tree node objects to insert into DOM.
I would like to know, if I do not have view / component which need to observe on any state or bidirectional binding(e.g. just render template by passed options, and handle events on DOM), does Virtual DOM will really make a difference in such scenarios?
Or it is as good as createDocumentFragment() if all it has to do is just rendering and no observing on state.

Answer 1

The simplest answer is that NodeJS does(/will) not have document.createDocumentFragment, nor document.createElement or any such thing.

The point of VirtualDOM is to allow for not only large-scale edits to systems where DOM will later be injected, but also to allow for any edits in an environment where the DOM just plain does not exist.

This is the largest difference between practical application of DocumentFragments and VirtualDOM.

Added benefits in terms of specific instances of DOM virtualization would be that certain view libraries (React, say) make dealing with these things quite simple, compared to manual insertion into fragments and their children.

Answer 2

Virtual DOM is a virtual representation of the UI tree. Its name is misleading as it's not linked to the DOM any more. Nowadays React can be used for web apps with react-dom or for mobile apps with react-native.

It's true that DocumentFragment and Virtual DOM are similar: tree like structures containing nodes with similar information. One could indeed use DocumentFragment to track changes and update the DOM when necessary. However it wouldn't be possible to use it on native development. Also the nodes will contain unnecessary properties and methods.