from Hacker News

Ask HN: What are the cons of Google Polymer?

by LukeFitzpatrick on 5/8/16, 12:29 PM with 77 comments

• by sshumaker on 5/8/16, 2:37 PM

  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.

• by david-given on 5/8/16, 1:53 PM

  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.

• by eob on 5/8/16, 2:35 PM

  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.

• by pfooti on 5/8/16, 3:17 PM

  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....

• by appleflaxen on 5/8/16, 2:29 PM

  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.

• by IshKebab on 5/8/16, 2:56 PM

  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.

• by lucb1e on 5/8/16, 1:51 PM

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

• by dccoolgai on 5/8/16, 1:49 PM

  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.

• by dominotw on 5/8/16, 1:39 PM

  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.

• by etimberg on 5/8/16, 2:51 PM

  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.

• by arisAlexis on 5/8/16, 2:29 PM

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

• by wanda on 5/8/16, 3:13 PM

  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?

• by sidcool on 5/8/16, 7:51 PM

  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

• by kolar on 5/9/16, 6:14 AM

  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.

• by elcritch on 5/8/16, 7:23 PM

  Don't forget to take a look at 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.

• by andreapaiola on 5/8/16, 1:46 PM

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

• by andreapaiola on 5/9/16, 5:20 AM

  And from a SEO point of view?

• by vayarajesh on 5/8/16, 1:48 PM

  It lacks a routing system