Lots of good answers, but the one thing I noticed nobody has mentioned (unless I missed it) is that "DOM" stands for "Document Object Model". The HTML is the "

Lots of good answers, but the one thing I noticed nobody has mentioned (unless I missed it) is that "DOM" stands for "Document Object Model". The HTML is the "Document". The DOM is an object oriented programmatic interface to the document. The DOM was used not just for HTML, but also for SGML and XML (if you use libraries like Sax). So the statement you have quoted is slightly confused (although a very common confusion). People think of the DOM as being essentially an AST of the document tree. The "Virtual DOM" is seen as kind of scratch pad for that tree: update the "virtual DOM" and the AST is automatically brought into sync. At that point the "DOM" (as Document Object Model) loses any meaning because it is no longer that object model (with it's completely insane API) that we all love to hate. Why are these AST diffs being done in userland libraries when it could be done by the browser itself. Because you already have a DOM. Why would you possibly want another programmatic interface? ;-) Though tongue in cheek, this is really historically the answer. The API you've got is the API you've got. Providing an ability to get the document as an AST and to update it by furnishing a new AST would be wonderful. But you've got to get it by the standards committee. Edit: I should point out that browsers used to support XSLT which allows you to transform the document declaratively based on the AST. Not sure if any browser still supports it though...