See, I had always thought that virtual DOM was one or two things: the building of the underlying structure as a separate list of nodes from what is displayed, and separately, a sort of buffered visual rendering on the (presumably more powerful) server that was used to determine exactly which elements needed to be rendered for the given view, then passing the associated DOM tree nodes to the browser for actual rendering. Kinda like double buffering and depth culling I guess?
Is there some thing that does this and I've just been getting ideas confused all this time?
This is how the Virtual Node tree is constructed. One case could be a React.createElement call that creates a virtual div node. You can visualize it by going to this page (Scroll down to the REPL section): https://millionjs.org/docs/api/basics/m
> a sort of buffered visual rendering on the (presumably more powerful) server that was used to determine exactly which elements needed to be rendered for the given view, then passing the associated DOM tree nodes to the browser for actual rendering
This is called hydration: https://en.wikipedia.org/wiki/Hydration_(web_development)
This is in contrast to the DOM, or the native rendering method for JavaScript, which requires developers to specify imperative steps to "construct" the user interface.
Virtual DOM is useful because it makes it much easier to create user interfaces, but comes at the cost of rendering performance. Million aims to make close the gap between DOM (native) and Virtual DOM performance through compilation, or optimizing certain "predefined routes" to native code, allowing for optimal rendering speed.
You can read more about virtual DOM here: https://millionjs.org/blog/virtual-dom