How performant are these polyfills (esp. in IE11)?

[mattdsteele]

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

For context: I'm interested in converting a set of AngularJS 1.x components to WCs, with Skate. We'd target IE11 + evergreens.

While doing some benchmarking I've found substantial performance hits when rendering web components, particularly in IE11. Slower than AngularJS 1.x, even I'm not sure if I'm doing something wrong in my benchmark, or if the polyfills themselves are slow, but I'd like another set of eyes on them.

Here's a few Webpackbins wherein I'm testing the load time to create 1k elements with various frameworks:

Framework	URL	IE11	FF	Chrome	Safari TP
Vanilla CE	https://www.webpackbin.com/bins/-KkurrXiOAGwv6DDVDt_	2905	534	190	170
Skate 5	https://www.webpackbin.com/bins/-Kkm6e7UGhPHnNUvRxXU	3579	683	183	277
Skate (no connectedCallback )		3409	776	192	288
Skate (no slot)	https://www.webpackbin.com/bins/-KkuibIirN3VlNrHvM40	2296	539	184	290
Vue	https://www.webpackbin.com/bins/-KkqHt9FOCoXV_qc7q_w	620	502	204	269
AngularJS	https://www.webpackbin.com/bins/-KkqLUTVDarHnAbziblD	608	445	263	271

(Note: Webpackbin doesn't work in IE11, so I had to download the bins and npm start them locally)

So yeah, I don't think this is an issue with Skate (as vanilla custom elements experience the same issue), but perhaps with ShadyDOM in particular. But we likely won't be able to go forward with a WC rewrite of our library if it's going to result in a 5x slowdown in the browser used by the majority of our customers.

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

[treshugart]

(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).

[treshugart]

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.

[mattdsteele]

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. 🎉

[treshugart]

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

[treshugart]

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.

[mattdsteele]

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!

[matthewp]

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

[treshugart]

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.

[treshugart]

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

[mattdsteele]

Wish I could say; I wasn't able to make it work in IE11 in prod mode 😐

…

On Wednesday, May 24, 2017, Trey Shugart ***@***.***> wrote: @mattdsteele <https://github.com/mattdsteele> In the web components issue, you said "Vue (dev mode)". Out of curiosity what is prod mode like? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXv1d6CdgTq63KCXJIYzqsf-SpqovgRks5r9Nd6gaJpZM4NlY3K> .

[treshugart]

IE9 and above

o_0