@saiki Thanks for the pointer! Unfortunately I did actually already create a DOM serialiser! Thanks for the interest too :). I just thought I might be barking up the wrong tree (see what I did there). Thanks again
So, does the vDOM do the WHOLE DOM? or just a specified singular element? I assume vDOM is based on something like MutationSummary (https://github.com/rafaelw/mutation-summary) for picking up changes to it? Furthermore is the vDOM essentially just a JSON/similar representation of the real DOM?
Is it possible to view/access the vDOM in react?
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.
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 - https://korynunn.wordpress.com/2013/03/19/the-dom-isnt-slow-you-are/