4 ms·

This chart[0] is why. No IE, Safari or Firefox. It's basically only fully supported by Chrome and Opera. Chrome may have the biggest piece of the pie these days

This chart[0] is why. No IE, Safari or Firefox. It's basically only fully supported by Chrome and Opera. Chrome may have the biggest piece of the pie these days, but every other framework supports all of them, so why take the risk that 30-60%[1] of your users can't use your app? [0]: https://www.polymer-project.org/0.5/resources/compatibility.html https://www.polymer-project.org/0.5/resources/compatibility.... [1]: Depending on what numbers you use.

spankalee 11y ago
This is the chart that matters: https://github.com/WebComponents/webcomponentsjs#browser-support https://github.com/WebComponents/webcomponentsjs#browser-sup... Polymer, via the web components polyfills, supports IE10+, Safari 7+, Chrome, Firefox, and Android Browser. The chart you linked to is for _native_ web components support, which is better because it's faster and more spec compliant, but not necessary. The polyfills are quite good. (btw, you're linking to the 0.5 docs, the 1.0 doc is here: https://www.polymer-project.org/1.0/resources/compatibility.html https://www.polymer-project.org/1.0/resources/compatibility.... )
- PopeOfNope 11y ago
  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.

spankalee 11y ago

This is the chart that matters: https://github.com/WebComponents/webcomponentsjs#browser-support https://github.com/WebComponents/webcomponentsjs#browser-sup... Polymer, via the web components polyfills, supports IE10+, Safari 7+, Chrome, Firefox, and Android Browser. The chart you linked to is for _native_ web components support, which is better because it's faster and more spec compliant, but not necessary. The polyfills are quite good. (btw, you're linking to the 0.5 docs, the 1.0 doc is here: https://www.polymer-project.org/1.0/resources/compatibility.html https://www.polymer-project.org/1.0/resources/compatibility.... )

PopeOfNope 11y ago
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.