9 ms·

Ask HN: What are the cons of Google Polymer?

dominotw 10y ago
you are kind of forced to use bower. lacks older browser support mixing it with other virtual-dom libraries like react is not easy or straightforward.
- kumpelblase2 10y ago
  What's the definition of "older browser" here? As far as I know, polymer also uses a polyfill [1] to provide the web components functionality to older browsers. [1] : https://www.polymer-project.org/1.0/resources/compatibility.html https://www.polymer-project.org/1.0/resources/compatibility....
  - andreapaiola 10y ago
    Yeah, but last time I checked it fails: for example there isn't a way to polyfill shadow DOM...
    - tdumitrescu 10y ago
      The difference between the webcomponents.js polyfill and webcomponents-lite.js is precisely that the former includes the shadow dom polyfill.
    - david-given 10y ago
      Polymer 1.0 doesn't use shadow DOM (unless you ask it to). Instead it uses this thing called 'shady DOM', which is roughly equivalent but requires accesses to the DOM to go through APIs. See here for the details: https://www.polymer-project.org/1.0/articles/shadydom.html https://www.polymer-project.org/1.0/articles/shadydom.html
  - TheCoelacanth 10y ago
    No support for IE9 even with polyfills. Some people can get away with not supporting IE9, but sadly I am not one of those people.
andreapaiola 10y ago
More http requests (or vulcanize, maybe...)
- nawitus 10y ago
  Yeah, you only need a single http request thanks to vulcanization.
- ergo14 10y ago
  With http 2.0 everything is piped in single request.
vayarajesh 10y ago
It lacks a routing system
- skamoen 10y ago
  Not anymore, with the carbon-route elements they built a pretty awesome routing system. https://elements.polymer-project.org/elements/carbon-route https://elements.polymer-project.org/elements/carbon-route
- wyqydsyq 10y ago
  It's not supposed to have one. Polymer is simply a shim and collection of WebComponents. Polymer isn't a fully-fledged application framework itself. You'd still use something like Flux, Redux or Cycle (with a router) on top of Polymer. Polymer is intended to be used essentially for views only - the same role React plays in the Redux + React stack.
dccoolgai 10y ago
For the moment, it doesn't really have great browser support and less intent to implement than some other features of the OWP. Whereas service workers at least had Mozilla pushing along with it, Google seems to be "going it alone" a bit more on Polymer and having a tougher time building a coalition for it.
- nawitus 10y ago
  Hmm, I've found that the polyfills work fine, if you need to target IE11 and latest Firefox/Chrome. Even old Chrome versions work well with the polyfill.
  - andreapaiola 10y ago
    The shadow DOM works in IE, all the spec?
    - nawitus 10y ago
      The shadow DOM polyfill works fine in IE. There are a few problems with IE though, the main one I've encountered is that dom-repeat doesn't work inside table.
  - andreapaiola 10y ago
    Firefox? Safari iOs?
    - nawitus 10y ago
      Yes to Firefox. I don't test Safari.
      - andreapaiola 10y ago
        For a public site is important...
- robdodson 10y ago
lucb1e 10y ago
For those who (like me) have never heard of it, here's a link: https://www.polymer-project.org https://www.polymer-project.org
- anc84 10y ago
  What is it though? The page does not say...
  - lucb1e 10y ago
    The examples seemed rather clear to me of what it is in general, but I didn't look at the details.
david-given 10y ago
It pretty much requires you to use the babel/crisper/vulcanize toolchain, which in my limited experience doesn't do nearly a good a job of minifying Javascript than other tools (because it can't do symbol renaming). I haven't found a way to use browserify with web components, for example, so no ES6 modules. Polymer is made of magic. It uses magic cutting-edge browser features where available, and where they aren't it fakes them using magic. Some of its APIs like Polymer.dom(x) are completely magic. When it works, it works really well. When it doesn't you are going to waste so much time trying to find out why. It also assumes that everything you're doing is through Polymer; so you won't get much mileage out of, say, JQuery. While it admits the existence of other Javascript libraries it tends to blank them at parties. If I were to do my current project again... I'd probably still choose Polymer, although I'd take another look at the other Javascript UI toolkits. Web components are so, so nice for designing UIs --- I can finally use actual computer science techniques like abstraction and modularity for building UIs! --- and it's got the best consistent look and feel that I've ever seen in a Javascript UI toolkit.
- jrmerz 10y ago
  Here's an experiment for ES6 and Polymer via Browserify + Babel: https://www.npmjs.com/package/poly-next https://www.npmjs.com/package/poly-next
- balloob 10y ago
  You can totally use ES6 modules, you just have to split the web component JavaScript and HTML into separate files. That's what we did for Home Assistant, which we documented here: https://github.com/home-assistant/home-assistant-polymer#building-the-app https://github.com/home-assistant/home-assistant-polymer#bui...
- sgtpep 10y ago
  >which in my limited experience doesn't do nearly a good a job of minifying Javascript than other tools (because it can't do symbol renaming). It's possible to extract js-code from the vulcanized html file to the separate js-file using the crisper command, than run the uglifyjs command with appropriate minification arguments. Example: vulcanize --inline-css --inline-scripts ./index.html | crisper -h ./build/index.html -j ./build/script.js cd ./build uglifyjs -m -c warnings=false -o ./script.js --source-map=./script.js.map ./script.js
arisAlexis 10y ago
If you want to compare with react for example or angular it lacks a mobile framework.
- stemuk 10y ago
  Well, only partly true. Because all paper/iron elements are adapting seamlessly on mobile, there is no real need for a mobile framework.
  - arisAlexis 10y ago
    I am talking about React Native and Ionic to build mobile apps with transferable skills
    - stemuk 10y ago
      True, but if you are looking for offline adaptions of your webapp there is a really cool technology called service worker that works as an offline cache for your whole app.
    - PixelsCommander 10y ago
      polymer-native is currently under active development and available on github
appleflaxen 10y ago
I've never used it, because the official demo site was incredibly slow. If the resources of google can't even make their own library feel responsive, then I'll spend my time hitting my head against a different platform.
- kentt 10y ago
  I'm assuming you mean https://elements.polymer-project.org/ https://elements.polymer-project.org/. It seems quite fast to me.
  - notthemessiah 10y ago
    What browser are you using?
    - codecamper 10y ago
      I noticed my latest version desktop Safari freezing up on their docs site.
      - wyqydsyq 10y ago
        The problem here is that you're using Safari.
        codecamper 10y ago
        it's all webkit, no?
eob 10y ago
We use it pretty extensively at Cloudstitch and like it on the whole. A few commenters mentioned poor browser support, but we haven't experienced any problems other than IE<=10. In many ways Polymer is just a shim for the WebComponents spec with data binding added in, along with a standard library of web components. The resulting framework-style is basically plain-JS/HTML with a la carte use of Web Components where appropriate. Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in. (Ironically the one thing you can't currently do is mix Polymer Elements from Source A with Polymer Elements from Source B at runtime if they have common, but separately hosted, dependencies). WebComponents feel a bit like Java swing, in that making HelloWorld is high overhead, but once you've got a nice toolbox of components going, you can pull them out and use them flexibly. This is not unlike React components, except Polymer/WebComponents use an HTML-centric definition format while React uses a JS-centric definition format.
- jamra 10y ago
  Wait a minute, you mean you had problems on IE 10? That's a widely used browser.
  - eob 10y ago
    I only recall problems on 9 actually, but I wanted to be careful not to oversell after checking the compat matrix
- danabramov 10y ago
  >Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in. For what it’s worth, you can integrate React in your existing Backbone/Ember/Angular/etc app one component at a time. At my previous company, we have been doing this over the course of a year while shipping new features thanks to the interactivity React enabled. Ryan Florence gave a talk about integrating React into an existing app: https://www.youtube.com/watch?v=BF58ZJ1ZQxY https://www.youtube.com/watch?v=BF58ZJ1ZQxY
  - PixelsCommander 10y ago
sshumaker 10y ago
Disclaimer: I led development of gaming.youtube.com. We chose Polymer at the time for non-technical reasons. Some downsides: Performance is not great. Lack of coherent data architecture (e.g. Redux). Difficult to manage state change (as opposed to React) due to a more limited programming model - e.g. template ifs and repeats don't know to reevaluate in many cases. This makes it harder to integrate with third party js libraries. Inferior tooling vs React. Philosophically Polymer is more about the DOM and React is more JS-focused. Some of this is personal preference.
- torgoguys 10y ago
  You answered the question asked, but I'm also curious as to what you liked about it for that project.
  - sshumaker 10y ago
    Pluses: It was vastly preferable to server-side template rendering (how YouTube is traditionally built). :) Generally well-built components with support for material design patterns. Polymer team was responsive to issues and quick to address feedback. Plus a bunch of non-technical reasons like developer mindshare within YouTube etc.
- nawitus 10y ago
  >e.g. template ifs and repeats don't know to reevaluate in many cases. Examples?
  - eob 10y ago
    There's a bit of hassle required to bind conditionals to object paths IIRC. Also CSS classes bound to variables don't work well if you're also using custom-style elements, which is virtually inevitable.
  - sshumaker 10y ago
    They don't re-evaluate on nested path changes, e.g. if (item.bar.isActive) won't trigger if isActive changes. You can work around this in practice but often it requires significant architectural changes and for your regular JS code to be Polymer-aware. This wasn't true in Polymer 0.6 but required Object.observe which is SLOW. React's render everything and diff approach avoids this issue.
etimberg 10y ago
I recently used Polymer for a large project. Performance is ok on chrome with full web-components, but unsurprisingly the full webcomponent polyfill is very slow elsewhere. Stick to the ShadyDom polyfill if possible. Vulcanize is pretty cool, though we had a hard time getting it to work right in a gulp workflow.
- abdonrd 10y ago
  Can you share this large project?
IshKebab 10y ago
Slow as hell in Firefox because Firefox doesn't natively support web components so they use a JavaScript polyfill. Also it is over-complicated for simple websites. You'll end up in bower-npm-grunt-etc-etc hell very quickly.
- spankalee 10y ago
  Are you using the full shadow dom polyfill or the Shady DOM shim? Shady DOM is _significantly_ faster as the cost of full spec compliance.
- callahad 10y ago
  > Firefox doesn't natively support web components FWIW, that's because there hasn't been a reasonably stable, agreed upon collection of specs for us to implement. Custom Element only reached multi-vendor agreement a few months ago (https://annevankesteren.nl/2016/02/custom-elements-no-longer-contentious https://annevankesteren.nl/2016/02/custom-elements-no-longer...). Polymer is a useful library, but it only represents a single vendor's vision, not any sort of standardized specification.
  - elcritch 10y ago
    Fair enough of a point. Web components have a lot of potential and it's good to hear Mozilla et al are slowly helping build consensus on the custom element instatiation! Polymer is one opinionated take on Web components which feels a bit heavy handed for my taste, I'm experimenting with x-tag from MSFT lately. Much lighter weight. The nice thing once these specs get finalized it'll be much easier to mix and max from whatever components you like (if they follow a DOM centric approach). One thing that's still frustrating is the lack of html rel import in Firefox. Any word if that's ever going to change? Http2 changes the performance constraints quite a bit so the previous decision not to support native html imports means you have to use vulcanize and you can't dynamically mix and match sources.
    - callahad 10y ago
      > the lack of html rel import in Firefox. Any word if that's ever going to change? Right now we have no intention of shipping HTML Imports; it's easy to polyfill, and we suspect that implementing ES2015 Modules and the module loader spec will change how we look at the problem of reusable components. To that end, support for a restricted subset of <script type="module"> should land in Firefox Nightly builds tomorrow (https://bugzil.la/1240072 https://bugzil.la/1240072), so we're making significant progress on that front.
wanda 10y ago
Excluding the performance issue, which largely seems to be confined to instances where polyfills are required, the cons don't seem so bad. The tooling will improve as the library and community mature, and other problems are being addressed already by the looks of it. I've got a project in the pipeline for which I was planning to use Cycle.js, but I've always had a niggling interest in Polymer. What I'd like to know is whether Polymer offers any significant pros, because after consuming some of the docs the offer seems to be a better reimagining of ASP.NET WebForms. What are the benefits?
pfooti 10y ago
If you are using the shady dom (web components lite, rather than the low perf full polyfill), the library requires you to do dom manipulation through the polymer local DOM API. [0] That means without shimming other libraries, polymer is incompatible with any other libraries you might use to manipulate the DOM. For example, you can't easily mix angular, react, or ember templates with some polymer elements, because (e.g.,) angular's ng-if directive doesn't use polymer.dom to inject created nodes. This is currently my biggest beef with polymer. Someday, webcomponents will be great, principally due to composability and portability. Just plug the one component you need in to your extant work. But for now, that promise is not quite realized. [0]: https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#dom-api https://www.polymer-project.org/1.0/docs/devguide/local-dom....
- spankalee 10y ago
  I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM polyfill was just too slow. Polymer can seamlessly switch between Shadow DOM and Shady DOM (though your own elements needs to be tested under both). You can still use the Shadow DOM polyfill is compatibility is a higher concern than raw performance. Safari and Chrome will have native Shadow DOM v1 implementations by the end of the year, and quite possibly Firefox. If we have enough resources, we may decided to make an IE/Edge specific Shadow DOM polyfill that'll be much faster because it'll path DOM prototypes rather than wrap DOM nodes. Wrapping is necessary because Safari doesn't properly let you patch Node prototypes. If this happens, we'll have fast and compatible DOM APIs.
  - pfooti 10y ago
    Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212
elcritch 10y ago
Don't forget to take a look at http://x-tag.github.io http://x-tag.github.io especially if you're looking for alternatives to Polymers take on a Web components. Haven't used either extensively yet but x-tag seems more bare metal.
sidcool 10y ago
An issue we faced is with different versions. Each new major version changed so much that we had to rewrite some things. I will wait for a stabler release
- balloob 10y ago
  I have been using Polymer since 0.5 and it used to be like this but since the first major version (1.0) it has not required me to rewrite anything.
kolar 10y ago
I've used Polymer.dart for browser game consiting mainly of simple windows. From that I can say the most important downside is the poor performance on mobile (even with shady DOM). Despite that I'd probably still choose Polymer if I need browser framework because webcomponents encapsulation feels great from developer perspective.
andreapaiola 10y ago
And from a SEO point of view?

you are kind of forced to use bower. lacks older browser support mixing it with other virtual-dom libraries like react is not easy or straightforward.

kumpelblase2 10y ago
What's the definition of "older browser" here? As far as I know, polymer also uses a polyfill [1] to provide the web components functionality to older browsers. [1] : https://www.polymer-project.org/1.0/resources/compatibility.html https://www.polymer-project.org/1.0/resources/compatibility....
- andreapaiola 10y ago
  Yeah, but last time I checked it fails: for example there isn't a way to polyfill shadow DOM...
  - tdumitrescu 10y ago
    The difference between the webcomponents.js polyfill and webcomponents-lite.js is precisely that the former includes the shadow dom polyfill.
  - david-given 10y ago
    Polymer 1.0 doesn't use shadow DOM (unless you ask it to). Instead it uses this thing called 'shady DOM', which is roughly equivalent but requires accesses to the DOM to go through APIs. See here for the details: https://www.polymer-project.org/1.0/articles/shadydom.html https://www.polymer-project.org/1.0/articles/shadydom.html
- TheCoelacanth 10y ago
  No support for IE9 even with polyfills. Some people can get away with not supporting IE9, but sadly I am not one of those people.

andreapaiola 10y ago

More http requests (or vulcanize, maybe...)

nawitus 10y ago
Yeah, you only need a single http request thanks to vulcanization.
ergo14 10y ago
With http 2.0 everything is piped in single request.

vayarajesh 10y ago

It lacks a routing system

skamoen 10y ago
Not anymore, with the carbon-route elements they built a pretty awesome routing system. https://elements.polymer-project.org/elements/carbon-route https://elements.polymer-project.org/elements/carbon-route
wyqydsyq 10y ago
It's not supposed to have one. Polymer is simply a shim and collection of WebComponents. Polymer isn't a fully-fledged application framework itself. You'd still use something like Flux, Redux or Cycle (with a router) on top of Polymer. Polymer is intended to be used essentially for views only - the same role React plays in the Redux + React stack.

dccoolgai 10y ago

For the moment, it doesn't really have great browser support and less intent to implement than some other features of the OWP. Whereas service workers at least had Mozilla pushing along with it, Google seems to be "going it alone" a bit more on Polymer and having a tougher time building a coalition for it.

nawitus 10y ago
Hmm, I've found that the polyfills work fine, if you need to target IE11 and latest Firefox/Chrome. Even old Chrome versions work well with the polyfill.
- andreapaiola 10y ago
  The shadow DOM works in IE, all the spec?
  - nawitus 10y ago
    The shadow DOM polyfill works fine in IE. There are a few problems with IE though, the main one I've encountered is that dom-repeat doesn't work inside table.
- andreapaiola 10y ago
  Firefox? Safari iOs?
  - nawitus 10y ago
    Yes to Firefox. I don't test Safari.
    - andreapaiola 10y ago
      For a public site is important...
robdodson 10y ago

lucb1e 10y ago

For those who (like me) have never heard of it, here's a link: https://www.polymer-project.org https://www.polymer-project.org

anc84 10y ago
What is it though? The page does not say...
- lucb1e 10y ago
  The examples seemed rather clear to me of what it is in general, but I didn't look at the details.

david-given 10y ago

It pretty much requires you to use the babel/crisper/vulcanize toolchain, which in my limited experience doesn't do nearly a good a job of minifying Javascript than other tools (because it can't do symbol renaming). I haven't found a way to use browserify with web components, for example, so no ES6 modules. Polymer is made of magic. It uses magic cutting-edge browser features where available, and where they aren't it fakes them using magic. Some of its APIs like Polymer.dom(x) are completely magic. When it works, it works really well. When it doesn't you are going to waste so much time trying to find out why. It also assumes that everything you're doing is through Polymer; so you won't get much mileage out of, say, JQuery. While it admits the existence of other Javascript libraries it tends to blank them at parties. If I were to do my current project again... I'd probably still choose Polymer, although I'd take another look at the other Javascript UI toolkits. Web components are so, so nice for designing UIs --- I can finally use actual computer science techniques like abstraction and modularity for building UIs! --- and it's got the best consistent look and feel that I've ever seen in a Javascript UI toolkit.

jrmerz 10y ago
Here's an experiment for ES6 and Polymer via Browserify + Babel: https://www.npmjs.com/package/poly-next https://www.npmjs.com/package/poly-next
balloob 10y ago
You can totally use ES6 modules, you just have to split the web component JavaScript and HTML into separate files. That's what we did for Home Assistant, which we documented here: https://github.com/home-assistant/home-assistant-polymer#building-the-app https://github.com/home-assistant/home-assistant-polymer#bui...
sgtpep 10y ago
>which in my limited experience doesn't do nearly a good a job of minifying Javascript than other tools (because it can't do symbol renaming). It's possible to extract js-code from the vulcanized html file to the separate js-file using the crisper command, than run the uglifyjs command with appropriate minification arguments. Example: vulcanize --inline-css --inline-scripts ./index.html | crisper -h ./build/index.html -j ./build/script.js cd ./build uglifyjs -m -c warnings=false -o ./script.js --source-map=./script.js.map ./script.js

arisAlexis 10y ago

If you want to compare with react for example or angular it lacks a mobile framework.

stemuk 10y ago
Well, only partly true. Because all paper/iron elements are adapting seamlessly on mobile, there is no real need for a mobile framework.
- arisAlexis 10y ago
  I am talking about React Native and Ionic to build mobile apps with transferable skills
  - stemuk 10y ago
    True, but if you are looking for offline adaptions of your webapp there is a really cool technology called service worker that works as an offline cache for your whole app.
  - PixelsCommander 10y ago
    polymer-native is currently under active development and available on github

appleflaxen 10y ago

I've never used it, because the official demo site was incredibly slow. If the resources of google can't even make their own library feel responsive, then I'll spend my time hitting my head against a different platform.

kentt 10y ago
I'm assuming you mean https://elements.polymer-project.org/ https://elements.polymer-project.org/. It seems quite fast to me.
- notthemessiah 10y ago
  What browser are you using?
  - codecamper 10y ago
    I noticed my latest version desktop Safari freezing up on their docs site.
    - wyqydsyq 10y ago
      The problem here is that you're using Safari.
      - codecamper 10y ago
        it's all webkit, no?

eob 10y ago

We use it pretty extensively at Cloudstitch and like it on the whole. A few commenters mentioned poor browser support, but we haven't experienced any problems other than IE<=10. In many ways Polymer is just a shim for the WebComponents spec with data binding added in, along with a standard library of web components. The resulting framework-style is basically plain-JS/HTML with a la carte use of Web Components where appropriate. Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in. (Ironically the one thing you can't currently do is mix Polymer Elements from Source A with Polymer Elements from Source B at runtime if they have common, but separately hosted, dependencies). WebComponents feel a bit like Java swing, in that making HelloWorld is high overhead, but once you've got a nice toolbox of components going, you can pull them out and use them flexibly. This is not unlike React components, except Polymer/WebComponents use an HTML-centric definition format while React uses a JS-centric definition format.

jamra 10y ago
Wait a minute, you mean you had problems on IE 10? That's a widely used browser.
- eob 10y ago
  I only recall problems on 9 actually, but I wanted to be careful not to oversell after checking the compat matrix
danabramov 10y ago
>Unlike [my perception of] React or Angular, you can use Polymer a bit without going all in. For what it’s worth, you can integrate React in your existing Backbone/Ember/Angular/etc app one component at a time. At my previous company, we have been doing this over the course of a year while shipping new features thanks to the interactivity React enabled. Ryan Florence gave a talk about integrating React into an existing app: https://www.youtube.com/watch?v=BF58ZJ1ZQxY https://www.youtube.com/watch?v=BF58ZJ1ZQxY
- PixelsCommander 10y ago

sshumaker 10y ago

Disclaimer: I led development of gaming.youtube.com. We chose Polymer at the time for non-technical reasons. Some downsides: Performance is not great. Lack of coherent data architecture (e.g. Redux). Difficult to manage state change (as opposed to React) due to a more limited programming model - e.g. template ifs and repeats don't know to reevaluate in many cases. This makes it harder to integrate with third party js libraries. Inferior tooling vs React. Philosophically Polymer is more about the DOM and React is more JS-focused. Some of this is personal preference.

torgoguys 10y ago
You answered the question asked, but I'm also curious as to what you liked about it for that project.
- sshumaker 10y ago
  Pluses: It was vastly preferable to server-side template rendering (how YouTube is traditionally built). :) Generally well-built components with support for material design patterns. Polymer team was responsive to issues and quick to address feedback. Plus a bunch of non-technical reasons like developer mindshare within YouTube etc.
nawitus 10y ago
>e.g. template ifs and repeats don't know to reevaluate in many cases. Examples?
- eob 10y ago
  There's a bit of hassle required to bind conditionals to object paths IIRC. Also CSS classes bound to variables don't work well if you're also using custom-style elements, which is virtually inevitable.
- sshumaker 10y ago
  They don't re-evaluate on nested path changes, e.g. if (item.bar.isActive) won't trigger if isActive changes. You can work around this in practice but often it requires significant architectural changes and for your regular JS code to be Polymer-aware. This wasn't true in Polymer 0.6 but required Object.observe which is SLOW. React's render everything and diff approach avoids this issue.

etimberg 10y ago

I recently used Polymer for a large project. Performance is ok on chrome with full web-components, but unsurprisingly the full webcomponent polyfill is very slow elsewhere. Stick to the ShadyDom polyfill if possible. Vulcanize is pretty cool, though we had a hard time getting it to work right in a gulp workflow.

abdonrd 10y ago
Can you share this large project?

IshKebab 10y ago

Slow as hell in Firefox because Firefox doesn't natively support web components so they use a JavaScript polyfill. Also it is over-complicated for simple websites. You'll end up in bower-npm-grunt-etc-etc hell very quickly.

spankalee 10y ago
Are you using the full shadow dom polyfill or the Shady DOM shim? Shady DOM is _significantly_ faster as the cost of full spec compliance.
callahad 10y ago
> Firefox doesn't natively support web components FWIW, that's because there hasn't been a reasonably stable, agreed upon collection of specs for us to implement. Custom Element only reached multi-vendor agreement a few months ago (https://annevankesteren.nl/2016/02/custom-elements-no-longer-contentious https://annevankesteren.nl/2016/02/custom-elements-no-longer...). Polymer is a useful library, but it only represents a single vendor's vision, not any sort of standardized specification.
- elcritch 10y ago
  Fair enough of a point. Web components have a lot of potential and it's good to hear Mozilla et al are slowly helping build consensus on the custom element instatiation! Polymer is one opinionated take on Web components which feels a bit heavy handed for my taste, I'm experimenting with x-tag from MSFT lately. Much lighter weight. The nice thing once these specs get finalized it'll be much easier to mix and max from whatever components you like (if they follow a DOM centric approach). One thing that's still frustrating is the lack of html rel import in Firefox. Any word if that's ever going to change? Http2 changes the performance constraints quite a bit so the previous decision not to support native html imports means you have to use vulcanize and you can't dynamically mix and match sources.
  - callahad 10y ago
    > the lack of html rel import in Firefox. Any word if that's ever going to change? Right now we have no intention of shipping HTML Imports; it's easy to polyfill, and we suspect that implementing ES2015 Modules and the module loader spec will change how we look at the problem of reusable components. To that end, support for a restricted subset of <script type="module"> should land in Firefox Nightly builds tomorrow (https://bugzil.la/1240072 https://bugzil.la/1240072), so we're making significant progress on that front.

wanda 10y ago

Excluding the performance issue, which largely seems to be confined to instances where polyfills are required, the cons don't seem so bad. The tooling will improve as the library and community mature, and other problems are being addressed already by the looks of it. I've got a project in the pipeline for which I was planning to use Cycle.js, but I've always had a niggling interest in Polymer. What I'd like to know is whether Polymer offers any significant pros, because after consuming some of the docs the offer seems to be a better reimagining of ASP.NET WebForms. What are the benefits?

pfooti 10y ago

If you are using the shady dom (web components lite, rather than the low perf full polyfill), the library requires you to do dom manipulation through the polymer local DOM API. [0] That means without shimming other libraries, polymer is incompatible with any other libraries you might use to manipulate the DOM. For example, you can't easily mix angular, react, or ember templates with some polymer elements, because (e.g.,) angular's ng-if directive doesn't use polymer.dom to inject created nodes. This is currently my biggest beef with polymer. Someday, webcomponents will be great, principally due to composability and portability. Just plug the one component you need in to your extant work. But for now, that promise is not quite realized. [0]: https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#dom-api https://www.polymer-project.org/1.0/docs/devguide/local-dom....

spankalee 10y ago
I'm on the Polymer team. Shady DOM is probably the biggest beef that we have with the project, but it was a very necessary tradeoff given that the Shadow DOM polyfill was just too slow. Polymer can seamlessly switch between Shadow DOM and Shady DOM (though your own elements needs to be tested under both). You can still use the Shadow DOM polyfill is compatibility is a higher concern than raw performance. Safari and Chrome will have native Shadow DOM v1 implementations by the end of the year, and quite possibly Firefox. If we have enough resources, we may decided to make an IE/Edge specific Shadow DOM polyfill that'll be much faster because it'll path DOM prototypes rather than wrap DOM nodes. Wrapping is necessary because Safari doesn't properly let you patch Node prototypes. If this happens, we'll have fast and compatible DOM APIs.
- pfooti 10y ago
  Yes, I'm definitely looking forward to the Real Shadow DOM being browser-supported. I was unable to use the full webcomponents polyfill in my own application, as it introduced gamebreakers with contenteditable-based rich text editors [0]. Putting polymer anywhere on my page meant my rich text editor (quilljs fwiw) broke on non-chrome browsers, even through I wasn't doing anything polymeresque with the editor. It was just the polyfill interacting poorly with the browser's range implementation. In my case (my application also heavily leaned on angular for routing and page-level templating), I couldn't mix-and-match angular and polymer and also maintain cross-browser support of the text editor. But I still am _super_ excited about the future of the webcomponents world. I mean, if nothing else, having well-namespaced element ids (if I have two editor components on the page, I can't just grab "#dateinput") will be great. I love the idea of directly attaching properties to DOM nodes, encapsulating templates, and projecting content into viewports. It's seriously rad. I am 100% on board with the notion, it's just the polyfill in the meantime that's problematical. https://github.com/webcomponents/webcomponentsjs/issues/212 https://github.com/webcomponents/webcomponentsjs/issues/212

elcritch 10y ago

Don't forget to take a look at http://x-tag.github.io http://x-tag.github.io especially if you're looking for alternatives to Polymers take on a Web components. Haven't used either extensively yet but x-tag seems more bare metal.

sidcool 10y ago

An issue we faced is with different versions. Each new major version changed so much that we had to rewrite some things. I will wait for a stabler release

balloob 10y ago
I have been using Polymer since 0.5 and it used to be like this but since the first major version (1.0) it has not required me to rewrite anything.

kolar 10y ago

I've used Polymer.dart for browser game consiting mainly of simple windows. From that I can say the most important downside is the poor performance on mobile (even with shady DOM). Despite that I'd probably still choose Polymer if I need browser framework because webcomponents encapsulation feels great from developer perspective.

andreapaiola 10y ago

And from a SEO point of view?