The “Virtual DOM” isn’t a real thing from the browser’s perspective: it’s just a coding style for generating updates to the real DOM, and the browser doesn’t care about anything until that point just as it didn’t care about jQuery’s internals. The promise was that a vDOM would be faster by avoiding unnecessary updates but that never panned out and the web moved away from IE6 so the React team removed that from their marketing materials to focus on developer ease of use.

In contrast, the Shadow DOM is a real browser concept and that affects everything the browser does. Until that arrived, embedding was challenging because anything you added could affect the rest of the document in some way. Now we have a way to put something into an arbitrary location and guarantee that it won’t leak out, and that frees browser developers to make some performance optimizations.

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

As a practical example, think about social media embedding where people need to write code which is safe to put on millions of pages. Obviously that was possible but it was tedious, and browser developers identified numerous performance hotspots around it over the years. This allows that to be simpler and safer, which is always a great combination.

It's basically to encapsulate things. You can define a custom element and style it how you always want it to look, and then when you set general style rules for the site you don't have to worry about it messing up something in the shadow elements. It's Google's replacement to `scoped` CSS.

The utility of the shadow DOM is in controlled isolation for both CSS and JS, because nether can arbitrarily reach into a shadow DOM's tree via the parent DOM. Although they can be made to intentionally affect it through the root element in a useful but controlled way.

A virtual DOM is just an abstraction in JS; whereas the shadow DOM is a feature of the browser engine. They are not really comparable, a shadow DOM _is_ the DOM. The confusion may come from the fact that it can be used in custom elements where MVCs might be involved again.

For example, encapsulating a third party widget, cookie banner or your main navigation. That way any CSS added inside the shadow DOM only affects those elements - you can safely write selectors like `h1` or `button` and they’ll only match what’s inside that same shadow root boundary.

When you have an extension that modifies a given page/injects them with some elements and you don't want the class names or styles of those elements to interfere with the class names and styles of the parent page. There are lots of extensions like this.

It scopes styling