|
|
|
|
|
by acdha
1227 days ago
|
|
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. |
|
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)