I've used Polymer for about a year now, and it's not my favorite.
Two way data binding yields bad design, and stack traces are incredibly opaque (they go through polymer guts). That means debugging is an absolute nightmare (I come from strongly typed closure javascript, so this was a punch in the face). If your HTML has problems, the browser won't yell at you; debugging tools are just plainly lacking. There's a reason Google doesn't use it widely.
So, it seems great at first because it does so much, but you realize you want some minor customization and you end up spending all your time trying to hack around it when you could have just written from scratch in the same time (for example, I wanted an iron-collapse to move upwards, and had to do some crazy CSS hackery to get that to work).
That being said, if you restrict Polymer with team style guide, it can be incredibly powerful for code reuse. My team has a style guide that looks like this: only use paper components if absolutely necessary, never use {{}} only use one-way data binding, and attach strongly typed javascript to the Polymer component classes with Closure or Typescript.
(I work at Google, was tech lead for the image search frontend team for 4 years, and now work on Tensorboard in Tensorflow which is Typescript + Polymer)
Two-way data-binding is definitely still controversial and/or can be hard to use in some cases, but its also very easy to use in others, and we've found it help people get started very quickly. I think it's important to know that it's an _option_ and has potential downsides. I'm not sure we communicate that enough. We do have large customers who follow a mostly-one-way pattern.
Speaking of, Google does use Polymer widely. All of YouTube is converting to Polymer right now, plus quite a large number of "smaller" projects like Play Music, Chrome, Translate, Chromecast, TensorFlow :), etc.
Two-way data binding is indeed a bad pattern, but the issue is that there is only syntax to bind data down, with [[]]. Sometimes it makes sense to get data from a child, and {{}} can be convenient, as long as you follow the rule that you only use it to retrieve data, and never try to set it. Unfortunately there is no syntax for such a binding, but as long as you follow the style that {{}} is only used as a one-way binding (but in the opposite direction compared to [[]]) it works just fine.
I usually create elements that are responsible for managing a certain type of data, and expose is through properties. This data can then be used anywhere in the application, by using that element and observing with {{}}. I really like that pattern, it feels like a traditional model object that exposes a nice API to consumers.
I definitely agree that you need a pretty strict style guide, it's too easy to go crazy and just stitch things together, and end up with an entangled mess.
I'm a big fan of the two-way data binding in Angular (though you do need to be aware of its limits), and I'd gotten the impression that Polymer was a bit of a spiritual successor to Angular. Any opinions on how the two compare?
Also, using the two way binding is optional. We've been using Polymer for about the same time with Redux and a unidirectional data flow. I'm very happy with it.
@nverba Hoi mate,
Any pointers about using redux with polymer? I have been using polymer for some eight months now. I tried to implement redux in one of my components a couple of months back. But I couldn't finish it, because of the humongous refactoring work.
You can check out polymer-redux (https://github.com/tur-nr/polymer-redux). It's makes it easy to integrate the redux store inside your components. Basically you will split up your components in two types: 1.) container components that are redux aware and subscribes to slices of your state graph and pure presentational components that are unaware of redux and are management by the container components.
This is similar to what is suggested in React/Redux. This way you can re-use your presentational components elsewhere.
I've had very similar experience with Angular 1.x where a lot of problems can be avoided by having a sensible styleguide/standard across the entire team. I've since moved to using React and couldn't be happier :)
Two way data binding yields bad design, and stack traces are incredibly opaque (they go through polymer guts). That means debugging is an absolute nightmare (I come from strongly typed closure javascript, so this was a punch in the face). If your HTML has problems, the browser won't yell at you; debugging tools are just plainly lacking. There's a reason Google doesn't use it widely.
So, it seems great at first because it does so much, but you realize you want some minor customization and you end up spending all your time trying to hack around it when you could have just written from scratch in the same time (for example, I wanted an iron-collapse to move upwards, and had to do some crazy CSS hackery to get that to work).
That being said, if you restrict Polymer with team style guide, it can be incredibly powerful for code reuse. My team has a style guide that looks like this: only use paper components if absolutely necessary, never use {{}} only use one-way data binding, and attach strongly typed javascript to the Polymer component classes with Closure or Typescript.
(I work at Google, was tech lead for the image search frontend team for 4 years, and now work on Tensorboard in Tensorflow which is Typescript + Polymer)