as Leon Fiedler mentioned the DOM is basically the in memory representation of you HTML markup as objects.
the Virtual DOM is the Representation of the Markup in memory as well. one of the key differences is the Virtual DOM is not rendered.
The rise of the virtual DOM was basically the conclusion that the paint time - the time your browser takes to paint your interface - is bigger than the calculation time. So directly applying changes to the DOM all the time, is more costly than 1 batch update.
To track your changes, but only apply them once, the Virtual DOM will be merged with the next version of itself after the update. So only the differences will be applied and this leads to an overall better performance of the browser.
'Diff merge based'
Does this answer help you to understand the why?
As an example
//the virtual dom looks something like this
{ 'div' => { 'class': 'btn btn-primary'}}
// which will be rendered to this
<div class='btn btn-primary'></div>
// so you add an id
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
//what the virtual dom now does is only applying the difference between
//the first and the second version which is the id
<div id='foo' class='btn btn-primary'></div>
// this is pretty basic but what if it happens 20 times?
// so i send the command
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
{ 'div' => { 'class': 'btn btn-primary', 'id': 'foo'}}
//these actually should never be applied.
This is still far from optimal, but it was the trade of what is more costly: the paint or the calculation if it should be painted.
This is how I understand it and we could go into more detail .... but this a key point
Sai explained the virtual DOM in this article. hashnode.com/post/the-one-thing-that-no-one-prope…