<story><title>Declarative Shadow DOM</title><url>https://webkit.org/blog/13851/declarative-shadow-dom/</url></story><parent_chain><item><author>MuffinFlavored</author><text>When would somebody want to use Shadow DOM instead of just the regular DOM? Is shadow DOM the next incarnation of the previous fad before it (virtual DOM)?</text></item><item><author>jacobr</author><text>Almost all examples of Shadow DOM uses Custom Elements, but that’s not required. I think this conflation harms adoption of Shadow DOM.&lt;p&gt;As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app&amp;#x2F;component in. So if you need a couple of React components on a page to not affect each others style, you can do React.createRoot(myShadowRoot) and they’re fully encapsulated.</text></item></parent_chain><comment><author>acdha</author><text>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.&lt;p&gt;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.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;Web_Components&amp;#x2F;Using_shadow_DOM&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;Web_Components&amp;#x2F;...&lt;/a&gt;&lt;p&gt;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.</text></comment>
<story><title>Declarative Shadow DOM</title><url>https://webkit.org/blog/13851/declarative-shadow-dom/</url></story><parent_chain><item><author>MuffinFlavored</author><text>When would somebody want to use Shadow DOM instead of just the regular DOM? Is shadow DOM the next incarnation of the previous fad before it (virtual DOM)?</text></item><item><author>jacobr</author><text>Almost all examples of Shadow DOM uses Custom Elements, but that’s not required. I think this conflation harms adoption of Shadow DOM.&lt;p&gt;As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app&amp;#x2F;component in. So if you need a couple of React components on a page to not affect each others style, you can do React.createRoot(myShadowRoot) and they’re fully encapsulated.</text></item></parent_chain><comment><author>tomxor</author><text>The utility of the shadow DOM is in controlled isolation for both CSS and JS, because nether can arbitrarily reach into a shadow DOM&amp;#x27;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.&lt;p&gt;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.</text></comment>