Ask HN: What are the cons of Google Polymer? - LukeFitzpatrick
======
sshumaker
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.

~~~
nawitus
>e.g. template ifs and repeats don't know to reevaluate in many cases.

Examples?

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

~~~
justjico
I agree this can be a pain and it does require significant architectural
changes, but needing "nested path changes" is also often a code smell calling
for better component encapsulation. The DOM/polymer already supports nesting
components.

~~~
elcritch
This seems to be a common assumption in the JS world. Even many polymer
elements seem to focus on providing stunts for JS procedural style programming
rather than DOM first programming. Do you have any good resources on
refactoring JS code to be more DOM centric? I'm thinking tools like d3.

------
david-given
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
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)

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

~~~
danabramov
_> 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
This is even easier with polymer or web components since you can use them in
any template or jsx as simple as you put there regular HTML tags

------
pfooti
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....](https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#dom-
api)

~~~
spankalee
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
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)

------
appleflaxen
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
I'm assuming you mean [https://elements.polymer-
project.org/](https://elements.polymer-project.org/). It seems quite fast to
me.

~~~
notthemessiah
What browser are you using?

~~~
codecamper
I noticed my latest version desktop Safari freezing up on their docs site.

~~~
wyqydsyq
The problem here is that you're using Safari.

~~~
codecamper
it's all webkit, no?

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

~~~
callahad
> _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...](https://annevankesteren.nl/2016/02/custom-elements-no-
longer-contentious)).

Polymer is a useful library, but it only represents a single vendor's vision,
not any sort of standardized specification.

~~~
elcritch
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
> _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.

~~~
elcritch
> it's easy to polypill,

It may be easy from an internal implementation point of view, but from a usage
point of view I disagree, unfortunately. It disallows using static html/css
only web-components which strongly goes against the grain of HTML's intent of
providing markup only documents. Granted it's a minor use case these days, but
it is important to the underlying philosophy of HTML and strongly limits the
feasibility of building a static html-only _and_ modular website. Let's say a
client's JS is disabled (via NoScript which addons.mozilla.org reports as
having 2 million users). In this case it'd completely break html-only web-
components for 2 million plus users, even components used primarily for CSS
modularity. Unless I'm missing something with how ES2015 modules will work...?
This seems like a major lack of support for any notion of custom-components
and particularly of user preferences on how they view the web. Which is
probably why this seems such (to me) an odd stance for the Firefox developers
to take. I'll be following the ES2015 modules to figure out if I'm missing
something in this!

Here's an example use case: tailoring static html based documentation with use
case based theming. Depending on the clients origin and/or browser type, it'd
be trivial to redirect http html-import requests to support various
themes/clients. While technically possible without native html-imports, it'd
require either JS support or dynamic rewriting of html files (essentially run-
time vulcanization on the server) rather than a simple http redirect to a
modular component.

> To that end, support for a restricted subset of <script type="module">
> should land in Firefox Nightly

It'll be interesting to see how ES2015 Modules and module loader spec eases
the day-to-day usage of web-components. Even with polyfills Firefox seems to
be difficult to coax into loading custom components -- vulcanizing the html is
the only method I've found to be reliable. I'll test drive the <script
type="module"> and file any bugs that I might find, thanks for the heads up!
The script module should support x-tag library pretty well.

------
lucb1e
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
What is it though? The page does not say...

~~~
lucb1e
The examples seemed rather clear to me of what it is in general, but I didn't
look at the details.

------
dccoolgai
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
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
The shadow DOM works in IE, all the spec?

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

------
dominotw
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
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....](https://www.polymer-
project.org/1.0/resources/compatibility.html)

~~~
andreapaiola
Yeah, but last time I checked it fails: for example there isn't a way to
polyfill shadow DOM...

~~~
david-given
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)

------
etimberg
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
Can you share this large project?

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

~~~
stemuk
Well, only partly true. Because all paper/iron elements are adapting
seamlessly on mobile, there is no real need for a mobile framework.

~~~
arisAlexis
I am talking about React Native and Ionic to build mobile apps with
transferable skills

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

------
wanda
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?

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

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

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

~~~
ergo14
With http 2.0 everything is piped in single request.

------
andreapaiola
And from a SEO point of view?

------
vayarajesh
It lacks a routing system

~~~
skamoen
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)

