How performant are these polyfills (esp. in IE11)? about web-components HOT 11 CLOSED

(Not sure this is the right venue for this; let me know if there's a better place to have this conversation)

The performance issues are most-definitely related to ShadyDOM as they patch the DOM interfaces. The Custom Element polyfill might add a little bit, but I would expect it to be acceptable. I'd say that it'd be a good idea to narrow it down to one or the other and then have the conversation in the respective repositories: https://github.com/webcomponents/custom-elements and https://github.com/webcomponents/shadydom.

Any idea what might be going on? Maybe my tests aren't good benchmarks of real-world behaviour?

If you want to test raw element creation, I think your tests are fine. The problem (at least to me) has been clear from the beginning: polyfills - at least in this respect - are going to be slow. Some can deal with it and some can't, and you'll have to make the best choice that fits your use case.

So most of your customers are still using IE11?

As a side note, it's nice to see Skate mostly beat everything else under native (and even get really close in polyfilled FF).

from web-components.

In looking at the benchmarks, the Skate one is unnecessarily calling super.connectedCallback(). It might be good to get rid of this. Classes and super calls are notoriously expensive in transpiled code.

from web-components.

I'd say that it'd be a good idea to narrow it down to one or the other and then have the conversation in the respective repositories

Makes sense. Should I focus on ShadyDOM or are you still maintaining CloudyDOM?

So most of your customers are still using IE11?

Yeah, corporate Win7 environment for the most part. Edge is our next step but it'll be a while.

the Skate one is unnecessarily calling super.connectedCallback(). It might be good to get rid of this.

Made the change, but didn't seem to affect things much.

it's nice to see Skate mostly beat everything else under native (and even get really close in polyfilled FF)

You guys are rocking the party that rocks the pinata. 🎉

from web-components.

Makes sense. Should I focus on ShadyDOM or are you still maintaining CloudyDOM?

cc @matthewp

Made the change, but didn't seem to affect things much.

Just in case :p

from web-components.

Yeah, corporate Win7 environment for the most part. Edge is our next step but it'll be a while.

I'm wondering what type of performance you'd get out of something like https://github.com/skatejs/ssr/blob/master/sd.js. It's still the early days, but that only patches the custom element, not every DOM interface. It doesn't use slots yet, though, but I'm not sure if it ever will.

from web-components.

Made a separate ticket at webcomponents/shadydom#155. I think we can close this one out.

I'm wondering what type of performance you'd get out of something like https://github.com/skatejs/ssr/blob/master/sd.js

I'm not entirely sure how this would be used. We haven't looked at SSR much; partially because we're developing lots of AngularJS 1.x apps, which aren't easy to SSR. But I'll be interested to see this develop; maybe an example of how it's used would help make this less opaque.

Anyhow, thanks again for your help!

from web-components.

I'm still maintaining cloudydom, but it's mostly just pulling down from shadydom, so best to start there.

from web-components.

Maybe something you could do would be to - instead of having 1000s of custom elements - to have a single custom element that accepts an array prop? Not sure of your use case, though.

from web-components.

@mattdsteele In the web components issue, you said "Vue (dev mode)". Out of curiosity what is prod mode like?

from web-components.

from web-components.

IE9 and above

o_0

from web-components.