3 ms·

There's no Shadow DOM support in Firefox or IE/Edge, and Safari support is buggy. http://caniuse.com/#feat=shadowdomv1 http://caniuse.com/#feat=shadowdomv1 The

There's no Shadow DOM support in Firefox or IE/Edge, and Safari support is buggy. http://caniuse.com/#feat=shadowdomv1 http://caniuse.com/#feat=shadowdomv1 The client-side polyfill for Shadow DOM requires executing JS before paint, which is slow. For optimum performance, you have to polyfill it server side, with a build tool. At that point, you might as well just pre-process it for all browsers, at which point, maybe you'd enjoy something more flexible than Shadow DOM, e.g. something that lets you share styles between components.

spankalee 9y ago
I'd double check your performance assumptions. Polymer-based sites are usually at the top of the list for perf shootouts, even though they tend to be purely runtime rendered. The key is only executing very little JavaScript and very carefully managing DOM creation. The ShadyDOM/ShadyCSS Shadow DOM shims are quite fast, and the benefit is that you don't need them when you have native Shadow DOM, vs a compile-time solution that you're likely married to and is proprietary. Shadow DOM gets faster automatically as browsers adopt standards, and portable and lasting knowledge is worth a lot. Safari's Shadow DOM implementation has improved a ton over the last year. Polymer 2.0 defaults to using it over the polyfills. caniuse.com needs to be updated - the second bug listed is fixed now.
- dfabulich 9y ago
  It depends on what you measure. Google argues that "time to interactive" is the correct number to optimize for; that's where Polymer-based sites shine. But nobody can beat streaming server-rendered (or ServiceWorker-rendered) HTML + CSS on a "time to paint" basis. Google claims that "time to paint" is the wrong measure, but if you're using progressive enhancement, TTP is all you need. Shadow DOM mostly sucks anyway for lack of a good way of sharing styles between shadow roots. (It's awesome that we can encapsulate CSS with shadow DOM, but that was too much encapsulation.)

spankalee 9y ago

I'd double check your performance assumptions. Polymer-based sites are usually at the top of the list for perf shootouts, even though they tend to be purely runtime rendered. The key is only executing very little JavaScript and very carefully managing DOM creation. The ShadyDOM/ShadyCSS Shadow DOM shims are quite fast, and the benefit is that you don't need them when you have native Shadow DOM, vs a compile-time solution that you're likely married to and is proprietary. Shadow DOM gets faster automatically as browsers adopt standards, and portable and lasting knowledge is worth a lot. Safari's Shadow DOM implementation has improved a ton over the last year. Polymer 2.0 defaults to using it over the polyfills. caniuse.com needs to be updated - the second bug listed is fixed now.

dfabulich 9y ago
It depends on what you measure. Google argues that "time to interactive" is the correct number to optimize for; that's where Polymer-based sites shine. But nobody can beat streaming server-rendered (or ServiceWorker-rendered) HTML + CSS on a "time to paint" basis. Google claims that "time to paint" is the wrong measure, but if you're using progressive enhancement, TTP is all you need. Shadow DOM mostly sucks anyway for lack of a good way of sharing styles between shadow roots. (It's awesome that we can encapsulate CSS with shadow DOM, but that was too much encapsulation.)