
Ask HN: Should I use Polymer for my next project? - HeinZawHtet
Should I Use Polymer from Google for next project?<p><i></i>What are advantages and disadvantages for using Polymer?<i></i>(www.polymer-project.org)
======
tinco
We are using it for implementing a rather large project. I plan on writing a
few articles on our experiences with it in the next couple of months.

What you need to keep in mind that Polymer is largely experimental software, I
would not recommend it yet for generic audience websites. The polyfills are
nice, but you have to keep a tight eye on performance, and a new browser
release could very easily pull out the rug from under you, as the Chrome
release last month did, and make your site not work for a large chunk of
users. I personally would not do it if I had a whole bunch of browsers I had
to test every single thing in.

It also takes a little while to get accustomed to the Polymer way of doing
things. Our app is a single page webapp and there's many things we had to find
out for ourselves. Most Polymer documentation is about rendering views, not
writing controllers or models that suit web applications.

From what I heard, they are working on a tighter integration with Angular. If
that would become an official thing it would probably improve their
opinionatedness on controllers/models. I personally am not a fan of Angular,
so perhaps I would not follow that anyway ;)

~~~
hhsnopek
I agree with this - to add on though:

Polymer DOES NOT replace models and controllers, use this to render, and
continue to use a MV* or MVC. Polymer gives you access to web components now
providing a polyfill. I love web components, but there when we have logic
inside a html is were I start to regret using it. example is [core-
ajax]([https://github.com/Polymer/core-ajax](https://github.com/Polymer/core-
ajax)) There is literally no reason to have this, this should be apart of your
javascript.

On that note you should use polymer, but don't combine your logic and
structure. I think of web components as advance templates that can be used. If
you implement your own web components keep your logic separate!

~~~
tinco
Yes exactly, this is one of the lessons we learned early on. The polymer team
have build a bunch of elements that actually represent services or models.
Their philosophy is that _everything_ can be a web component.

We experimented with this a bit, but quickly found this to be rather
worthless, it effectively means you have changed the location of your services
from the Javascript namespace to the DOM.

I'm not saying that's terrible, just that it does not have any clear advantage
to me, and a clear disadvantage would be that your services have to be
accessed through the dom using for example element.getElementById() instead of
just accessing them as they are defined on window or however the angular
people do it with their fancy dependency injections.

That said, we do pull of some nice tricks that involve a bit of logic through
combining components, and we do use web components as controllers. It is a bit
like old school ASP.net code behind, but I like it.

edit: I have to be fair, I just remembered the advantage they aim for. When
your services and models are also webcomponents, then you can make your
dependency on them explicit using html imports, which would be the HTML5
solution for the problem RequireJS solves.

------
dfreedm2
One important question: Do you need to ship something right now?

If so, its important to keep in mind that Polymer is in a "developer preview"
state, and we have not declared it production ready yet.

If you need to ship, then use whatever you feel the most comfortable with.
Fewer cognitive barriers and less stress.

However, if you've got the time to play around and learn how web components
work, then hop aboard!

There's an introduction tutorial here: [http://www.polymer-
project.org/docs/start/tutorial/intro.htm...](http://www.polymer-
project.org/docs/start/tutorial/intro.html)

The calculator demo is pretty simple: [http://www.polymer-
project.org/components/paper-calculator/d...](http://www.polymer-
project.org/components/paper-calculator/demo.html) (source:
[https://github.com/polymer/paper-
calculator](https://github.com/polymer/paper-calculator))

Salesforce has a nice polymer-based web component set for building mobile apps
that integrate with the Salesforce apis:
[https://github.com/ForceDotComLabs/mobile-ui-
elements/](https://github.com/ForceDotComLabs/mobile-ui-elements/)

And the demo app at I/O is here: [http://www.polymer-
project.org/apps/topeka/](http://www.polymer-project.org/apps/topeka/)
(source:
[https://github.com/polymer/topeka/](https://github.com/polymer/topeka/) and
[https://github.com/polymer/topeka-
elements](https://github.com/polymer/topeka-elements))

~~~
bsimpson
That's consistent with what we've been hearing from Matt, but I believe
contrary to how Rob answered a similar question at I/O.

Do you guys have a timeline for this, e.g. "try it for production-quality apps
that are scheduled to ship Fall 2014"?

------
chrismonsanto
The Polymer website uses Polymer and it is slooooow. That's a huge red flag to
me.

I have nothing but good things to say about React. Try that instead.

~~~
tkinom
Agree, Designer tool looks kinda nice.

BUT, it is slow in FF30, Safari and failed a lot in IE11.

IMO, Big G is trying very hard to push web technologies that tightly couple to
Chrome - same as what MS/IE did a few years back trying hard to force ActiveX,
Silverlight down the developers' throat.

I'm betting < 20% chance Polymer will still be in IO talk 3 years from now.
(remember GWT, Dart, Angular?)

~~~
higherpurpose
People keep confusing this it seems. What Google is doing here is NOT like
what Microsoft did. Google is merely implement many new HTML5 features _ahead_
of Microsoft (which is usually the most behind in HTML5 support) and others.

So it's not that they are "built for Chrome". It's that they are built for
"new HTML5 specs" and only Chrome happens to support them right now. Point me
to where Silverlight was an HTML spec?

Now, things like NaCl on the other hand _are_ a lot more similar to what
Microsoft used to do, but there's still a _major_ difference, and that is that
what they are building is open source and everyone can do their own
implementation of it. You could never do that with ActiveX or Silverlight.
Plus, you could also say Firefox is doing the same as Google with asm.js,
which nobody else has adopted so far.

These things are a little more like that, but at least they are open source.
The HTML5 features, though, just happen to be implemented faster by Chrome.

~~~
tkinom
> "at least they are open source"

Kinda of remind me of how "open" android is progressing. More and more
"features" are pushing into "google experience" layers - also look at how open
is the android TV.

BTW, chrome is doing the same on the extension side.

I see the pro/con on the "extension move" \- reduce the security risk , etc.

But it is sure feel like the Jedi master is feeling the power of the dark side
- "working within the system" is not as fun as just being the Empire.

------
shadowmint
A couple of down sides of web components:

\- they interact poorly with requirejs and amd in general.

\- they flat out dont work at all in IE8

\- there's no 'good' solution for the request hell you get from loading 50
components; although some of the tooling is getting there (vulcanize).

\- the tooling in general is currently rubbish; no way to easily combine sass
+ jade + coffee into a web component (eg. with gulp, no the dart bindings
don't count as tooling). no way to have external resource files.

...but despite that all, they're fantastically productive, great for testable
ui, great for making reusable elements you can use in multiple projects.

Short answer is: yes, unless you have to support IE8.

~~~
DCKing
> \- they interact poorly with requirejs and amd in general.

> \- the tooling in general is currently rubbish; no way to easily combine
> sass + jade + coffee into a web component (eg. with gulp, no the dart
> bindings don't count as tooling). no way to have external resource files.

If you use Dart and its Polymer libraries, these two things should not be a
problem. Why does that not count? He didn't say he wants to use Sass, Jade or
CoffeeScript.

IMO, Dart is becoming much more interesting to me as it seems it is the best
way to work with Polymer.

~~~
rektide
Most javascript developers want to use Javascript and want to use what's
available in the defacto javascript package manager (npm) and want to use the
build tool that works with the javascript packages (browserify). Suggesting
using something other than Javascript, it's packages, and it's preeminent
packager to get started with Polymer is exactly the problem parent was
highlighting, and your suggestion is bloody not well helping.

~~~
DCKing
Why the hostile reaction? Expanding your horizons is not a bad thing.

> Most javascript developers want to use Javascript

OP mentions nothing, parent mentions CoffeeScript.

Dart also has packages and an official package manager. It also has a
dogfooded official Polymer library. Setting up a modular toy project with
packages was easier to understand in Dart than JS for me. I don't see how I'm
"bloody well not helping".

------
epayne
My plan: go all in on Angular (wish it were Ember or Backbone) through 2015.
These frameworks have reached a maturity and popularity that makes them useful
and reliable. I expect to switch to Polymer / Web Components early 2016. I
work at a very large company. I think it makes sense for us to stay in the
"late majority" because most benefits come for technology adopters after the
trail has not only been blazed but has been thoroughly paved and landscaped by
others. There may be competitive advantages however to individual developers
and smaller organizations (startups) who can pioneer the new.

------
joemaller1
I really liked the Polymer demos from I/O, but stepping back, it seems an
awful lot like React without the compatibility.

Polymer does appear to be more than just another Google flash-in-the-pan.
They've got a good team, which is working closely with the Chrome team and
Google's investment at I/O was significant. I wonder how the Angular folks are
feeling.

Facebook is using React right now, when will Google put Polymer into
production? Hopefully Polymer will get around to some practical compatibility.
Otherwise I'll make a note in my calendar for 2016.

~~~
ffreire
Perhaps the biggest concern right now is vendor buy-in from other browser
vendors such as Microsoft and Apple. It appears that React, at least for the
time being, is a more immediate and practical approach to composing UIs.

I'll still be mixing Polymer into internal/side projects to keep up to date on
its status, but I don't think I'll be pushing anything public facing for the
foreseeable future.

------
STRML
I used it for a project about a year ago
([https://github.com/STRML/securesha.re-
client/tree/master/pol...](https://github.com/STRML/securesha.re-
client/tree/master/polymer)). I found that it was difficult to keep the
service up and working; while older browsers still seem to load it quite well,
Chrome continues to natively implement parts of the (changing) spec.

When Polymer detects native capability for a given feature, it turns its
polyfills off. But if the spec has changed, you are no longer supporting the
spec as it was when you wrote your code; and inevitably, your application will
crash.

I think Polymer has a lot of potential - I definitely enjoyed using it (check
out the `app/elements/raw-xhr` and `webworker` elements for some fun;
invisible DOM elements that process data!). But if I were to do another
application like this, I think I'd just do it with React. It's less of a
moving target and has a lot of the same benefits (and more), with the
exception of CSS sandboxing.

~~~
dfreedm2
Sorry to hear about that. Thankfully the specs are done now that everything is
shipping in Chrome 36.

I hope you'll find some useful web components in the future that you can just
drop in to whatever project you're working on and save some time!

~~~
STRML
Is that so - are the specs final now?

------
jastanton
I have been playing a lot with Polymer over the last 4 months or so. Here are
my thoughts:

From what I can tell Polymer works closely with the Chrome team and the
features that this "framework" offers are really just upcoming tech that is
being built into chrome and is being made available by Polymer. Things like
web components, html imports, templating etc... are built built into the
browser so the longer you use polymer the less of polymer you will use.

When I describe polymer to people I say it's an opinion layer on top of
upcoming tech. And in addition to that everything is polyfilled to some older
browsers, but right now is aimed towards the evergreen browsers.

When you ask "should I use Polymer", what I hear is, "should I get a jump
start on the upcoming future of the web"? Lets be clear here, Mozilla, IE,
Chrome etc... are all merging on these technologies. Object observers,
templating, web components etc... are all emerging, Polymer is just one way
you can use them now and tie them all together in an opinionated way. If you
don't like it you don't have to use polymer you could just use plain ol JS and
achieve the exact same solution, just slightly more verbose and with less
support.

Now as to wether or not you should use it? Depends who your audience is. If
you need a huge wide support from old browsers, probably not. If you're doing
tooling for your company then yeah I would, it would be great to get used to
the way the web is migrating towards. Just keep in mind everything is still
solidifying, so there might be some awkward corner cases or something, but
honestly it's just plain old Javascript soooo it's pretty vanilla so you
shouldn't have too much difficulty if you know JS.

Last thing I have to say about Polymer. It's going to stretch the way you
think of the DOM and JS. The way everything is structured and the way you
should be thinking about it is that every DOM node should be considered an
instance of a class. The DOM node exposes an API and away you go plugging and
playing into the rest of your JS. It's really fun once you get used to it.
This will really stretch you when they introduce the ajax api as a DOM node.
wat. Crazy things are happening, some good, some will need to be changed.

Full disclosure I work at Google as a software engineer that specializes in
frontend, so I am exposed to this a lot though I do NOT work on the project.
That's about it :)

------
robin_reala
Why would you? I’ve never been a fan of adopting technology for technology’s
sake without a problem that you’re trying to solve with it. (n.b. that problem
could acceptably be ‘I want to learn more about this technology’)

~~~
bsimpson
1) If Web Components work as-advertised, we'll be able to build our own
primitives for the first time in the history of the web stack; no more
shoehorning rich Internet apps into a framework that was designed for
academics to share term papers. This is both fantastic and a fundamental shift
in the way apps are written.

2) You can make web apps that look and feel native (on Android) for free.

~~~
robin_reala
Sorry, I phrased my original post badly. That wasn’t a rhetorical question, it
was posed to the OP. They didn’t give any reasoning as to why they wanted to
adopt Polymer, just a blanket ‘should I?’. Your reasons are both valid though.

------
transientbug
So I've been porting part of our internal analytics system at work over to
using polymer and I have to say: damn. It's nice to have and being able to
make custom reusable elements that can expose a preset functionality and a
powerful (if you write it that way) api is pretty nice. Overall I'm pretty
happy with it, but can't really speak for how usable outside of our little
sphere it is.

We haven't had any issues with speed or page performance and only target
chrome however.

------
tangue
Polymer looks like a project to push boundaries. While I found the demos at
i/o quite cool; I'll quietly waiting for Angular (or Ember if you're this kind
of person) to implement Web Components...

------
timothya
I haven't built an application in Polymer yet (though I did have a good
experience building a small application about a year and a half ago with
Dart's WebUI library, which implemented a lot of the Web Component features
before Polymer and the web browser layer was ready), so I don't have any
advice on how ready Polymer is for prime-time yet.

What I will say is that we should remember that Web Components is where the
web platform is going. This isn't some one-off library by Google; both Chrome
and Firefox are getting all of the web component primitives built into the
browser, and it looks promising that we'll see them arrive in IE and Safari as
well. Polymer is some sugar on top of those primitives to make them easier to
work with, but in any case, the next generation of web apps will start using
web components and probably some library like Polymer or XTags. The time to
start learning and playing around with web components is _now_ , even if it's
not time to build massive applications in them quite yet.

------
dilipray
Pros: Because Polyfill is who web should be built. It's the best way to
develop a web applications. It's future friendly.

It's better to have one file for a component. Example:
[https://github.com/PolymerLabs/google-
map](https://github.com/PolymerLabs/google-map) Where they have everything.
CSS, JS and Template in one page.

Cons: You shouldn't be using it for everything and of course not for the next
project. Google doesn't use it for production. It makes tons of requests.

Comments:

Try to use it for few demo projects test the performance and take a decision.
If you want to use it. It works best with require.js and you can't just dive
into it Polymer(Deep Sea) without having experience(Wearing a oxygen
cylinder).
[https://gist.github.com/tantaman/7222599](https://gist.github.com/tantaman/7222599)

------
bennycreative
I'm not sold on the idea that you need Web Components (and thus Polymer/React)
to build or maintain a complex web app. I think that "complex" can mean a lot
of different things. I know from experience that things like <canvas> and Web
Workers are already showing a lot of promise by bringing multi-threaded
processing to the browser for graphics- and other CPU-intensive operations.
I'm also excited for WebRTC, the telephony APIs, WebGL, and other things.
These things will help us build complex web apps.

When it comes to code maintainability, there is no shortage of organizational
frameworks (backbone, angular, etc.), utility libraries (jQuery, underscore,
etc.). These are helping me build complex apps.

What is Polymer doing for me? Allowing me to use Web Components and shadow
DOM? Oh, how earth-shattering. No thanks.

------
wereHamster
It depends on what kind of website or web app you are working on.

I noticed that polymer is not really suitable for highly dynamic web
applications. With ReactJS you can use all of the javascript control
structures (if/then/else, conditions, loops, functions etc). With polymer you
are restricted to bind, repeat and ref, which are not enough to adequately
cover the requirements of a complex application.

My recomendation is to use polymer if it's a mostly static website with just a
few moving parts, and ReactJS otherwise.

~~~
spankalee
Polymer is used to build very complex applications.

Not only do Polymer templates have bind, if, repeat, and ref, which are enough
to cover the _vast_ majority of cases, by they work by binding to an
expression which can drive more complex behavior.

I'm curious what you think you can't do with Polymer templates?

~~~
wereHamster
I didn't say polymer can't do it. What I'm saying is that certain constructs
are more difficult to write in polymer. Or involve more code and indirection.

Most apps will have their core data loaded into nice JavaScript objects and
class instances. With react the transformation of that data into DOM is a one
step process. With polymer you have to first map that data to javascript
primitives which are consumed by expressions which then generate the DOM.

I guess ultimately it's my preference to having types (I use TypeScript) which
can be used inside the rendering code to ensure correctness. With polymer you
lose some of that because everything ends up in these untyped expressions.

------
nobleach
I would go with the idea behind Polymer but probably not Polymer itself. Most
of the newer frameworks have some sort of component analog. Angular has
directives, Ember has components. You can simulate components with
Backbone/Marionette. ReactJS is AWESOME and fits right in with the whole
component mentality. The project I did with straight Polymer was fun, but I
ended up having to scrap it, as the Chrome last month caused blocker issues.

~~~
spankalee
Angular directives, Ember components, or any other framework's components are
not the same as Web Components. The browser doesn't, and won't ever,
understand what they are. They have very weak encapsulation unless used solely
within a single framework. You can't easily use them across frameworks.

The current battle of frameworks has lead to massive fragmentation. Pulling
together a React view with an Angular dropdown and an Ember tree view is damn
near impossible.

Web Components are real elements. You can use them wherever you can use
elements - including in all those other frameworks. That's the difference.

------
user1241320
I would also be interested in comparisons with
[http://www.x-tags.org/](http://www.x-tags.org/)

~~~
ffreire
Well, there's this little blurb in the faq[0], not sure if that helps you any.

[0][http://www.polymer-
project.org/resources/faq.html#xtags](http://www.polymer-
project.org/resources/faq.html#xtags)

------
ilaksh
I hope that the Mozilla people are working closely with the Google people on
Polymer, and vice versa.

If you are building an internal tool or an application where you can dictate
that they use a specific version of Chrome or Firefox then I think you should
default to Polymer now. Or at least default to trying to make it work first
before going on to other things.

------
bradchoate
What is it about the home page that makes the font face (on everything) adjust
weight as you hover on different things? This even happens in Chrome. That
can't be by design.

[http://cl.ly/image/062Q0F0h1T1s](http://cl.ly/image/062Q0F0h1T1s)

------
chawk
I've just played around with it, I hate it at first glance. It's like Google
is now saying we need to follow their pattern to make a responsive website.

------
wnevets
do you care about < IE10?

~~~
taf2
no :)

------
higherpurpose
Use it if you have an Android app, too, at least.

------
general_failure
For a mobile project, it is just too slow. I would go with ember

------
greenjello
The only reason to use polymer is if you need the L style UIs they discussed
at Google I/O.

While Google's really good at Java apis, they're really terrible at JS apis. I
love Google, but I would be very hesitant to use their JavaScript libraries or
frameworks. A lot of people I've talked to (on irc, es-discus, etc.) don't
agree with web components, but Google's pushing it hard.

Web components are poorly based good ideas, and polymer is poorly based on web
components, and your app will be (poorly) based on that.

Other people have started posting some of the problems with polymer.

~~~
bsimpson
I don't know if it's fair to say an entire organization is good or bad at an
individually-attributable skill. The Polymer team wrote the app framework for
WebOS. They're not some generic Java guys who got put on a web project. They
have a pretty deep background in JS.

