Update README.md

[AndyOGo]

added reference to webreflection polyfills

fixes #14

[justinfagnani]

I would object to this wording. The "slow" link references a feature to deviate from spec-compliance for better performance. There's no evidence given here that other polyfills are faster, or that they've even considered this case. If they do synchronous upgrade, then they're just as "slow". If the do async upgrade, they're not spec compliant. If the have an option, then they're equivalent to the @webcomponents polyfill. Basically, this is hearsay.

Also, while the @webcomponents polyfills do indeed have a detailed known issues section, that doesn't mean that other polyfills are without their known issues (a fully faithful polyfill might not be the right choice in all cases after all). Indeed, in the text below there's already a "constructor caveat" which, honestly, is a huge problem if I read it correctly. It seems to mean that most standard custom elements won't work because they won't have their constructor written in such a specific way. There's also a "caveats" section: https://github.com/WebReflection/document-register-element#common-issues--caveat Pointing out the @webcomponts known issues without pointing out the others comes across as disingenuous.

[AndyOGo]

@justinfagnani
Thanks for your opinion.

I'm sorry that you feel this is hearsay. Please correct me, but the link I attached clearly states:

The polyfill gets slower as the size of your page and number of custom element definitons increases. You can use polyfillWrapFlushCallback to prevent redundant work.

You are right, also WebReflection's polyfills comes with caveats.
That's why I mentioned them too, as you can see below:

please note the constructor caveat ...

My purpose here is to be objective and show the good and bad parts clearly.

May I ask, do I touch work of yours?
I mean do I criticize work you where involved?

[justinfagnani]

I'm sorry that you feel this is hearsay. Please correct me, but the link I attached clearly states:

The polyfill gets slower as the size of your page and number of custom element definitons increases. You can use polyfillWrapFlushCallback to prevent redundant work.

This is true because the spec states that upgrades must be synchronous. That same spec applies to all polyfills, so the real question is "slow compared to what". If you have reason to believe that the other polyfill avoids this slowdown, that would be good to point out, but otherwise there's no reason to believe that the other polyfill is faster in this regard.

My purpose here is to be objective

This really didn't come across as objective, because the claims are fairly unsupported and asymmetrical: they imply that other polyfills don't have similar issues simply because they don't list them.

[AndyOGo]

@justinfagnani
Thanks for your quick answer. I understand.

Well that point is best shown objectively by a benchmark.
Right now, I can only tell you what I observed myself. I created a patterns-library with custom-elements, we started out with the @webcomponents polyfill - which was fine for the first components. As we started to have dozens of components. Our demo pages got really slow in polyfilled browsers like IE11 and Firefox at that time, and with slow I mean 10 seconds time-to-interactive.
So I started to research and found above performance issue, found another polyfill by WebReflection, replaced it and boom, problem solved, less than 2s time-to-interactive in polyfilled browsers like IE11 and Firefox 😲

This is my humble experience with using both polyfills.

Of course I'm absolutely open to a more gentle rewording.

[AndyOGo]

@justinfagnani PS:
Again, may I ask, do I touch work of yours?
I mean do I criticize work you where involved?

[AndyOGo]

@justinfagnani
I just reworded it.
Please let me know what you think.
Or provide a suggestion if you still disagree.

[web-padawan]

Right now, I can only tell you what I observed myself.

I would recommend removing any mentions of slowness from here, until we have a proper benchmark.

[AndyOGo]

Thanks for your recommendation @web-padawan

I agree, that a proper benchmark is the ideal provision of objective information.

From the viewpoint of a consumer and builder of custom elements, we have a very high demand for performance and information about these facts are essential for us.
Just for the reason that these limitation is officially documented here (that's nothing I came up with):
https://github.com/webcomponents/custom-elements#customelementspolyfillwrapflushcallback

Personally I would prefer to not hold back this important fact.

If you guys insist, I will not struggle to reword it again.

[web-padawan]

The most bullet proof and battle tested polyfills I found

This a personal judgement and shouldn't be formulated like that. The current wording is biased. Ideally, all the polyfills should by listed in the same manner, and their limitations too.

[AndyOGo]

@web-padawan
You are right, it's based on my own observation and usage of both polyfills. These are just my honest findings, sorry if it offends any of you. But please don't accuse me for pointing it out.

Agree, I will try to find a more diplomatic wording.

[AndyOGo]

@web-padawan
@justinfagnani
@shawnbot
I removed the mention about slowness and mention of my own opinion.

I hope you agree with the new wording. Please let me know.

[AndyOGo]

@web-padawan
@justinfagnani
@shawnbot
Hy guys, I'm looking forward to your feedback, hope you have some free time available soon.

[web-padawan]

Would be nice to link for the browser support separately:
https://github.com/ungap/custom-elements-builtin#compatible-with-

So, we might want to rephrase "fantastic" to "evergreen" browser support in this case.

[web-padawan]

@AndyOGo added one comment, apart from that, I don't have any other suggestions.
I will try to adapt this PR to web-padawan/awesome-web-components#43

[AndyOGo]

@web-padawan Great, thanks for your feedback.
I just committed suggested changes 👍

[AndyOGo]

@shawnbot
Any updates on this?

As far as I know I have addressed all concerns of @justinfagnani and @web-padawan