3 ms·

For those asking what does it mean: Some web browsers use a DOM to make up UI elements (e.g. sliders, web video element etc). This allowed browser developers t

For those asking what does it mean: Some web browsers use a DOM to make up UI elements (e.g. sliders, web video element etc). This allowed browser developers to make these elements using DOM elements. It's called a Shadow DOM because you can't actually get access to the DOM elements within each UI element via Javascript. Q. Why is Apple doing this? A. They're moving this stuff to native code in an effort to speed up rendering on mobile.

magicalist 13y ago
> Q. Why is Apple doing this? A. They're moving this stuff to native code in an effort to speed up rendering on mobile. This doesn't really make sense, so I assume you're extrapolating from the commit comment. There is no "this" to move, first of all, and the shadow DOM was already "native code" for whatever that means, anyway. See om2's comment for what the whole "60fps on mobile" comment meant: https://news.ycombinator.com/item?id=7243328 https://news.ycombinator.com/item?id=7243328
- Someone 13y ago
  Even in native code, having the shadow DOM may slow down code. A web page is a tree of nodes. With shadow DOM, you replace 'native button here' nodes by trees of nodes ('rounded rect with text inside it') that can be individually styled. If you store those shadow DOM trees in the full page hierarchy, any JavaScript that walks the tree must inspect every node for its 'part of shadow DOM' bit (code that asks for all div's shouldn't see any div's in the shadow DOM) That slows down those walks. If you store them outside of the full hierarchy, your rendering code (which must walk the shadow DOM nodes) must know to inspect each node to see whether it has a shadow DOM tree. That slows down rendering. On top of that, more code = more cache misses, more code = less room for user data, and your nodes likely will grow a bit in size (at least on average) if you add that 'part of shadow DOM' bit. I don't have the faintest idea how large the effect of all this is, but there will be an effect.
  - tedmielczarek 13y ago
    FWIW, no web browser uses native platform controls to render HTML form controls. Shadow DOM just gives developers a way to encapsulate what they're already doing on the web.

magicalist 13y ago

> Q. Why is Apple doing this? A. They're moving this stuff to native code in an effort to speed up rendering on mobile. This doesn't really make sense, so I assume you're extrapolating from the commit comment. There is no "this" to move, first of all, and the shadow DOM was already "native code" for whatever that means, anyway. See om2's comment for what the whole "60fps on mobile" comment meant: https://news.ycombinator.com/item?id=7243328 https://news.ycombinator.com/item?id=7243328

Someone 13y ago
Even in native code, having the shadow DOM may slow down code. A web page is a tree of nodes. With shadow DOM, you replace 'native button here' nodes by trees of nodes ('rounded rect with text inside it') that can be individually styled. If you store those shadow DOM trees in the full page hierarchy, any JavaScript that walks the tree must inspect every node for its 'part of shadow DOM' bit (code that asks for all div's shouldn't see any div's in the shadow DOM) That slows down those walks. If you store them outside of the full hierarchy, your rendering code (which must walk the shadow DOM nodes) must know to inspect each node to see whether it has a shadow DOM tree. That slows down rendering. On top of that, more code = more cache misses, more code = less room for user data, and your nodes likely will grow a bit in size (at least on average) if you add that 'part of shadow DOM' bit. I don't have the faintest idea how large the effect of all this is, but there will be an effect.
- tedmielczarek 13y ago
  FWIW, no web browser uses native platform controls to render HTML form controls. Shadow DOM just gives developers a way to encapsulate what they're already doing on the web.