| In using shadow DOM, one thing that's become clear is that it is a developer productivity tool (built in the browser). With React, you have to use inline styles (https://facebook.github.io/react/tips/inline-styles.html) or a build tool to modularize/prefix CSS selectors (e.g. CSS Modules). Inline styles can muck with specificity and tons of inline styles can actually force the browser to do more context switching than necessary (HTML parser <-> CSS parser). Mind you, the latter is unlikely to actually be a perf issue in a real app. In shadow dom, you just write CSS. Write simple selectors in a `<style>` or a stylesheet, the browser automagically scopes the selectors to the component, no tools required. Shadow roots also prevent outer styles from cross the boundary and leaking in. That one is particularly tricky without help from the browser. As for perf... In theory, the browser can optimize work (style recalcs, layout, paint) in shadow trees b/c the DOM is local. However, generally there's a lot of low hanging fruit still to look at. Browser engines have been optimized for global css so those paths are super fast right now. https://bugs.chromium.org/p/chromium/issues/detail?id=314303 is a good example of the work that can be done (now fixed in Blink): > Being inside a ShadowRoot disables lots of optimizations we have for the normal document. Authors also use ShadowRoots differently than the main document (ex. hundreds of tiny identical sheets in each Shadow instead of one really big one in the document) so we should consider those use cases and how we can handle them better. > We should be able to get much faster. This bug tracks the many efforts to make recalcStyle faster in ShadowRoot (and by extension Web Components) Another thing Blink does is optimize `<style>`s so they're shared/cached across instances of a component (as long as their `.textContent` is the same). That was a pretty big speed up in Blink. |