custom-elements
custom-elements copied to clipboard
shawnbot
Update README.md
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.
@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.
@justinfagnani PS: Again, may I ask, do I touch work of yours? I mean do I criticize work you where involved?
@justinfagnani I just reworded it. Please let me know what you think. Or provide a suggestion if you still disagree.
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.
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.
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.
@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.
@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.
@web-padawan @justinfagnani @shawnbot Hy guys, I'm looking forward to your feedback, hope you have some free time available soon.
@AndyOGo added one comment, apart from that, I don't have any other suggestions. I will try to adapt this PR to mateusortiz/webcomponents-the-right-way#43
@web-padawan Great, thanks for your feedback. I just committed suggested changes 👍
@shawnbot Any updates on this?
As far as I know I have addressed all concerns of @justinfagnani and @web-padawan