Almost all examples of Shadow DOM uses Custom Elements, but that’s not required. I think this conflation harms adoption of Shadow DOM.
As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app/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.
Honestly, I had it the other way for quite a while: Shadow DOM harmed my adoption/excitement of Custom Elements for a long time. :) I spent quite a while back in the day with x-tags and other Web Component things, trying to avoid Shadow DOM, because I wanted everything on the page & not nested in subdocuments.
These days I'm more open to anything. It's definitely a bit exciting everytime I need to parse something with Shadow DOM, a lot more work to really understand what the page is. Last thing I had to parse was chrome://gpu, and it took 3 hours instead of 1 hour to do the job, but could have been worse. But it was at least possible. Sometimes though, with closed shadowroot, the page has gained a resistance to userscripts (as this commenter reports[1]), and this seems purely evil/bad/totalitarian, in a distinctly un-web way!
Weirdly Web Components and Shadow DOM are both tools in the same effort, but Web Components is trying to get everything clearly onto the page, and Shadow DOM has always felt like trying to hide a lot of the page; as someone who loves the web as an interchange of information, Web Components seemed interesting & enriching & useful & value add, and Shadow DOM seemed like a tightening/winnowing/control thing, that didn't express my values. More neutral today, and seeing things like CSS styling performance wins it's clear there are solid technical wins for the platform, but especially closed Shadow DOM feels so overtly control-oriented & totalistic in design, in direct counter to the openness / togetherness / intertwingularity that made the web so interesting & rich & unique a computing space. (It still remains unclear to me that closed shadow-root disappearing into your own pocket universe ought to be permitted, but I'm not as scared as I was.)
> Shadow DOM seemed like a tightening/winnowing/control thing
This is useful when you need to apply constraints on teammates, same as applying a linter to your project's CSS. You need to guarantee your internal components work well together.
If your style is more "make a component and throw it over the wall for people to use," making everything "public" may be a better approach.
But most web components will never be public or shareable, and that's OK.
Custom Element Registries can become a problem for organizations with multiple teams working on the same page, as they may inadvertently create elements with the same name, or need bug fixes or new features causing conflicts and preventing individual teams from deploying updates.
The result is that teams need to coordinate their updates and deploy them simultaneously, slowing down the development process. This problem has been recognized in the Web Components community, and some initiatives are underway to address it, such as Scoped Custom Element Registries.
Scoped Custom Element Registries provide a way to isolate the scope of custom elements, preventing name collisions and enabling individual teams to work independently on their components without affecting the rest of the page. This approach has the potential to improve the development process for organizations with multiple teams and streamline the deployment of updates.
However, this solution is not widely adopted yet, and it may take some time to gain traction. In the meantime, organizations may need to develop their own internal guidelines and procedures to manage custom element name collisions and coordinate their updates.
I hear you. I think Shadow DOM is very useful for a handful of roots on your page, encapsulating third-party widgets or DOM-heavy components like a nested navigation.
Custom Elements on the other hand are useful for attaching behavior to HTML, sort of like jQuery plugins.
Not at all sold on the frameworks promoting using Shadow DOM for every button or whatnot.
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)?
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.
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.
> Now we have a way to put something into an arbitrary location and guarantee that it won’t leak out,
Except that it does leak in practice. My company uses shadow DOM, but then to style stuff these use a lot of `--var`s, and apparently those penetrate the shadow DOM so you can still break other components inadvertently. (Admittedly when I saw that cluster* I retreated to the backend so my experience is limited)
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.
As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app/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.