5 ms·

Chrome 53 Beta: Shadow DOM, PaymentRequest, and Android Autoplay

29 points by itayadler 10y ago

borplk 10y ago
Does Shadow DOM have any significance on other things like React? (for example performance gains or similar?)
- scarlac 10y ago
  As far as I can tell, not right now. I think it'll allow for better isolation for your components but besides that I wouldn't expect major performance improvements.
- gedy 10y ago
  It does for Polymer and Webcomponents, but not specifically for React, since React ignores all this and does everything in JavaScript vs the DOM. It might indirectly help React for scoping CSS.
- ebidel 10y ago
  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 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 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.
- spankalee 10y ago
  The performance gains can be significant. Styles in shadow roots have less rules, styles lower selectivity than in global styles. The browser takes into account the shadow scopes when doing style invalidation and recalc, and so typically recalculates much less of the tree. Like ebidel mentions, the developer side is important too. You get to write simpler selectors and know that you aren't accidentally styling other parts of the document. I'd go so far as to say that Shadow DOM fixes most of the problems with CSS.
  - merb 10y ago
    I wonder when the performance degrades. Consider a angular app which contains 100-200 components (shadow-roots) on a single page. I mean theoretically it will still be faster since incremental-dom now see's less Node's for every root, but I thing the memory usage will probably way higher.
    - spankalee 10y ago
      There's the cost of an extra node, since a shadow root is a node. It shouldn't be too much overall though. Angular doesn't use incremental-dom, but yes, incremental-dom could walk smaller subtrees. incremental-dom could also walk smaller subtrees by calling it on small containers too. That's probably already the common pattern for componentized users of incremental-dom. I'm not sure why the memory usage would be much higher.
      - merb 10y ago
        angular2 uses it. I have an additional node. considering I change a upper shadow-root which has 50+ shadow-roots it's 50 more node's. We have lists which have a component per cell and per row which is like 100x10 lines. That would mean 1000 x 2 node's more? Changing the whole table would probably be way slower without the inner shadow-root's.
allendoerfer 10y ago
HTTP/0.9 has been deprecated in favor of HTTP/1.0, which adds response header support. Wow, I would not like to maintain software that has to support obsolete standards for another 20 years after they died. But somewhere in a basement a terribly infested server just got very lonely.

29 points by itayadler 10y ago

borplk 10y ago

Does Shadow DOM have any significance on other things like React? (for example performance gains or similar?)

scarlac 10y ago
As far as I can tell, not right now. I think it'll allow for better isolation for your components but besides that I wouldn't expect major performance improvements.
gedy 10y ago
It does for Polymer and Webcomponents, but not specifically for React, since React ignores all this and does everything in JavaScript vs the DOM. It might indirectly help React for scoping CSS.
ebidel 10y ago
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 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 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.
spankalee 10y ago
The performance gains can be significant. Styles in shadow roots have less rules, styles lower selectivity than in global styles. The browser takes into account the shadow scopes when doing style invalidation and recalc, and so typically recalculates much less of the tree. Like ebidel mentions, the developer side is important too. You get to write simpler selectors and know that you aren't accidentally styling other parts of the document. I'd go so far as to say that Shadow DOM fixes most of the problems with CSS.
- merb 10y ago
  I wonder when the performance degrades. Consider a angular app which contains 100-200 components (shadow-roots) on a single page. I mean theoretically it will still be faster since incremental-dom now see's less Node's for every root, but I thing the memory usage will probably way higher.
  - spankalee 10y ago
    There's the cost of an extra node, since a shadow root is a node. It shouldn't be too much overall though. Angular doesn't use incremental-dom, but yes, incremental-dom could walk smaller subtrees. incremental-dom could also walk smaller subtrees by calling it on small containers too. That's probably already the common pattern for componentized users of incremental-dom. I'm not sure why the memory usage would be much higher.
    - merb 10y ago
      angular2 uses it. I have an additional node. considering I change a upper shadow-root which has 50+ shadow-roots it's 50 more node's. We have lists which have a component per cell and per row which is like 100x10 lines. That would mean 1000 x 2 node's more? Changing the whole table would probably be way slower without the inner shadow-root's.

allendoerfer 10y ago

HTTP/0.9 has been deprecated in favor of HTTP/1.0, which adds response header support. Wow, I would not like to maintain software that has to support obsolete standards for another 20 years after they died. But somewhere in a basement a terribly infested server just got very lonely.