5 ms·

And why would I bother with the increased load time and complexity when I can use a framework that's natively supported? "Because Pollyfills" isn't a good enoug

And why would I bother with the increased load time and complexity when I can use a framework that's natively supported? "Because Pollyfills" isn't a good enough argument.

spankalee 11y ago
The work that the polyfills do: custom element registration and lifecycle, DOM composition, style encapsulation, is the same work that other frameworks do, they just do it in a proprietary way, and usually in a way that's incompatible with normal DOM usage. Current frameworks are no more "natively supported" than the polyfills anyway - it's all just code using the DOM. Given that all browser vendors are implementing Shadow DOM now, and are very close to starting on custom elements, choosing the polyfill route means that in a couple of years you will be able to have less load time because the polyfills are unnecessary. It also means that your elements will be compatible with the ecosystem of web components, not just the proprietary component system of whichever framework you chose. Plus, the model is actually quite simple: custom elements are just elements. That's a big deal when using other libraries. But you shifted reasoning between your comments. First you claimed that Polymer wasn't supported on any browser but Chrome, which is false (though I do think that the compatibility page isn't clear enough), then you question whether polyfills are worth it. As always, if you're looking for reasons to not use something, I'm sure you'll find them - that goes for any library or framework.
- PopeOfNope 11y ago
  Look, the question was "why don't more people use Polymer." That's the answer: it's not natively supported, or not perceived to be natively supported, or whatever. I work with companies who make the decision to use one framework over another all the time. That chart inevitably makes an appearance and polymer gets rejected immediately. If you feel strongly enough about the framework, get them better marketing.

And why would I bother with the increased load time and complexity when I can use a framework that's natively supported? "Because Pollyfills" isn't a good enough argument.

spankalee 11y ago

The work that the polyfills do: custom element registration and lifecycle, DOM composition, style encapsulation, is the same work that other frameworks do, they just do it in a proprietary way, and usually in a way that's incompatible with normal DOM usage. Current frameworks are no more "natively supported" than the polyfills anyway - it's all just code using the DOM. Given that all browser vendors are implementing Shadow DOM now, and are very close to starting on custom elements, choosing the polyfill route means that in a couple of years you will be able to have less load time because the polyfills are unnecessary. It also means that your elements will be compatible with the ecosystem of web components, not just the proprietary component system of whichever framework you chose. Plus, the model is actually quite simple: custom elements are just elements. That's a big deal when using other libraries. But you shifted reasoning between your comments. First you claimed that Polymer wasn't supported on any browser but Chrome, which is false (though I do think that the compatibility page isn't clear enough), then you question whether polyfills are worth it. As always, if you're looking for reasons to not use something, I'm sure you'll find them - that goes for any library or framework.

PopeOfNope 11y ago
Look, the question was "why don't more people use Polymer." That's the answer: it's not natively supported, or not perceived to be natively supported, or whatever. I work with companies who make the decision to use one framework over another all the time. That chart inevitably makes an appearance and polymer gets rejected immediately. If you feel strongly enough about the framework, get them better marketing.