An Introduction to Polymer - A Web Component Library (opens in new tab)

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)

1) Very easy to learn, but it has no idiomatic way to write large applications; it is not a framework like Angular or Ember.js. What the best way is to write large, maintainable, applications with Polymer is still open IMHO.

A potentially useful way to structure large Polymer based applications is to combine Polymer and Redux, separating presentation code from state/business logic.

2) No idiomatic way to do dependency injection. In Polymer even services are stated declaratively in HTML (e.g. `<my-service data={{resourceData}}></my-service>`). Because of this, there is no natural way to replace my-service with, for instance, a stubbed version for testing purposes. There are some solutions, but they are somewhat laborious [1].

3) Build process still buggy. We encountered multiple issues with the polymer-vulcanize library.

Looking back at the ease with which I started writing application code using Polymer I foresee a great future for this library, especially for smaller applications. We need to learn more best practices in order to use Polymer to create large maintainable applications.

[1] “Polymer - Dependency Injection with Custom Elements by Justin Fagnani” https://www.youtube.com/watch?v=6o5zaKHedTE

I have to say it's been a pleasure to use - coming from Angular 1.0. I like it has a very low barrier to entry, having only one real concept; Web Components.

Polymer gives you Data Binding and a few nice things on top of that, but for the most part, you're writing things fairly vanilla.

It's definitely not without it's problems. Element inheritence doesn't really exist in 1.X unless you use Behaviors. There's no inline expression support in bindings. This is partially good because it forces you to keep logic in your javascript, where it belongs. But it also means you sometimes have to be more verbose in obvious places:

   <span hidden$='[[thingsAreEqual(a,b)]]>They are not equal</span>

   <span hidden$='[[a==b]]'>They are not equal</span>

Given how Polymer components are typically written with the JavaScript included with the HTML file of the component this was not really an easy option for a beginner.

However using tools like polymer-build with gulp you can still get TypeScript support. In the upcoming Polymer 2.0 release TypeScript typings are going to be included with the library!

- Polymer is only available through bower, which means I have to teach 2 package management systems to my developers.

- The documentation is not great (for instance, events are documented in camelCase, but must be listened for in Angular 2 using dashes-between-words).

- There are serious issues [0] which not gone resolved for a long time.

- The behavior of important components is not intuitive. For instance, the menu component acts more like a list which has a selected item (which also cannot be reselected)

[0]: https://github.com/webcomponents/webcomponentsjs/issues/541

My opinion is that, polymer is good for specific use cases such as- Creating leaf level components, Reusing components around multiple projects.

BUT....

Building complete applications in Polymer has been a painful experience

I have at times encountered critical 'library bugs', which haven't been fixed yet, we had to use hacky workarounds and forked repos with fixes. Check 'p1-backlog' in github

Less control over elements because of two-way-data binding, I guess I should use redux with it. But I'm still a bit confused about certain aspects of adding redux into the mix

The application end up really heavy

I wish I had a bit more control over vulcanize

What I like about it most is that it lets me program for the web like I would normally code for software projects without UI. You can completely deconstruct your application into components and encapsulate logic and responsibility, giving you all the tools you need for great architecture. I am traditionally more of a backend guy, but Polymer makes building frontend projects fun for me, because the most interesting thing about programming to me is software architecture, creating powerful abstractions and designing interaction and APIs.

I have been working with Polymer since the first beta release (before 0.1) and completed multiple projects, both at work and during my free time. It has not been without it's problems. I have to say that it takes quite a while before it really 'clicked', because you have to learn quite a few patterns to make things work. If you started early on, it was very unpolished (despite that, we have a fairly large Polymer 0.5 application running in production, and it's still chugging along nicely), and the upgrade process is extremely painful (hence aforementioned application still running 0.5). It can also be dangerous, because if you don't know what you're doing, it is easy to end up with some frankenstein contraption that performs terribly, and is a horror to maintain. My advice to anyone looking to get into Polymer is to get advice from more seasoned developers, the Slack channel[1] is a great resource for that. Learn from existing projects and applications as much as possible to see how they solve the issues you will run into, and get a feeling for how the general architectural patterns work.

The good part is that all the techniques you learn are almost directly applicable to the future native Web Platform, as one of the core concepts of Polymer is that it tries to emulate what the future Web Platform will look like, and allow you to use that platform today. Quite a large part of the platform is already natively supported on most of the evergreen browsers, and I find that I use less and less Polymer code these days and use more and more plain native code. One day we may no longer use Polymer at all, but your newly learned skills will still apply.

A recent side project of mine has been an exploration of what future Web Applications might look like, and to test what is possible on the platform today. I built it completely from scratch, with no libraries or dependencies other than Polymer:

- https://overwebs.ruph.in (warning: sound and relatively high bandwidth. Works best in Chrome, other browsers untested)

[1] https://polymer-slack.herokuapp.com/

What about JS Modules?