Facts and Friction about Polymer and Web Components

The hype

If you're working in web / mobile / UI / UX development and haven't been living under a rock for the last couple of years, you've probably heard about Web Components and Polymer.

The marketing phrase says "Web Components usher in a new era of web development based on encapsulated and interoperable custom elements that extend HTML itself"; lots of people are genuinely excited about a concept that promises to profoundly challenge and change the way we're writing web and mobile applications.

jQuery and a whole plethora of web development frameworks built upon it suddenly seem to fall out of fashion and become obsolete now. Even the future of Angular and React is questioned by some, as Polymer core elements overlap part of the functionality already implemented by those frameworks. On the other hand I've read numerous articles and seen quite a few presentations showing you how you can integrate Polymer in your existing / ongoing Backbone/Marionette / React / Whatever.js project.

Reality check

Well, leaving the marketing story aside, let's try to look beyond the hype. I won't go into technical details (usually that's where the devil is), but Web Component specs have certainly been around for a while, and although everybody agrees we're in desperate need of a better way to deal with the issues they're addressing, the major browsers haven't been exactly quick in providing the native support. Right now, Chrome seems to be the only one offering a full implementation, while the guys at Mozilla are still debating whether they should support HTML imports or not and the guys at Microsoft are, as always, completely out of the loop (no, apparently they won't do it in Spartan either).

Some people said "no problem, we can polyfill the other browsers" (in plain English, polyfill means to compensate the missing features by providing non-native JavaScript implementations written in JavaScript). And thus, X-Tag, Bosonic and Polymer where born. Among them, Polymer seems to be the game-changer to keep an eye on, for a number of reasons, most notable because it looks fantastic and works really well (in Chrome), especially since the addition of material-design Paper Elements.

So, what's the problem if the other contemporary browsers are polyfilled?

We can use Polymer today, right?

Well, maybe... but make sure to check & double-check everything. For one reason, polyfills are great, but performance is one of the issues you should pay special attention to. Don't rely on the hype, decide for yourself. Take your time to study these samples across multiple browsers, OSes and devices and make sure to keep an eye on the developer console to see what happens behind the scenes.

We can integrate Polymer into our Backbone+Marionette / Angular / React based applications, can't we?

Technically speaking, yes, you can. But it doesn't mean you should. Sometimes starting from tabula rasa is just better. Let me give you just one reason (which should pertain to common-sense) that often developers excited about a new technology choose to ignore:

• jQuery: 82KB (or Zepto: 24KB)
• Underscore.js: 15KB
• Backbone.js: 20KB
• Marionette.js: 39KB
• WebCompoments.js: 103KB

And most likely your application will actually require a lot more, since you're probably using a touch-friendly slider, Google Maps, etc... and maybe Twitter Bootstrap. And some of them also come with lots of CSS code (fyi, CSS is executed too, and sometimes the execution can be costly).
As a side note, an important part of that code inevitably provides duplicate / obsolete functionality.

All that adds up to hundreds of KB of highly compressed JavaScript/CSS code that the browser has to download, understand and execute, without even considering the actual application payload. And that's an optimistic case because Backbone.js+Marionette.js is a lean framework for the functionality it provides.

All this may not seem like much nowadays, but not everybody has an unlimited 4G data plan and the latest flagship smartphone. Developers and tech-savvy people usually do, most normal people don't :-). Which means they'll only get the polyfilled, less-than-ideal UX experience.

I've seen a lot of promising web / mobile projects ending up awfully wrong because of UX code clutter. Sometimes developers without real web experience just "throw up a ThemeForest template or skin on top" of an enterprise application, sometimes they became so accustomed to working on the latest iMac or MacBook Pro that they simply forgot there are people out there using Windows laptops or cheap Android phones.

So, the bottom line is this: if you're brave enough to embrace Polymer today, maybe you should consider not mixing it up with "legacy" jQuery-based codebase. They're not always complementary and the mix will most certainly introduce a cost, aside from the benefits.

I'm writing code in CofeeScript/TypeScript, LESS/Stylus and Jade/HAML template engine, and I pack everything with Browserify. Can I "plug-in" Polymer in my workflow?

Well, good for you. You're probably an adept of terseness and simplicity, like me :-)
The bad news is you can't easily integrate Polymer in your workflow - and again, maybe you shouldn't. Among other things, CoffeeScript (which I use constantly and love, btw) appeared to compensate for some of the lacks of pre-ES6/7 JavaScript, and some of those are now polyfilled by webcomponents.js; Polymer was made with Bower in mind and comes with a specific packaging tool called vulcanize (a decision sometimes criticized by JS community members).
If you're building a Polymer-based project, there's no real reason to add browserify to the mix, except to show that it's possible.

I'm addicted to LiveReload; since I've discovered it, I simply can't work without it. It works with WebComponents / Polymer, right?

For people who haven't (yet?) heard about it, LiveReload is a tool / set of tools that brings an enormous boost in developer productivity by automatically reloading web assets as they change (images, fonts, stylesheets, scripts), without reloading the entire page. While this at first sight may seem like a trifle, it's actually invaluable: consider you're working on a context-dependent dynamic application, and during the development process you need to bring some visual adjustments by modifying some stylesheets. Without LiveReload, you'd have to hit "refresh", which is no big deal... but what if it takes you a few minutes to reach the same point in the application workflow? Plus, if your server-side is .NET, restarting the debug process in Visual Studio takes forever.

The bad news is that currently LiveReload doesn't play nicely with Polymer. I've been quite disappointed to discover this, but it doesn't. Updating an element will trigger a full page reload, while modifying a linked stylesheet won't trigger a reload at all. Which kind of defeats the purpose of LiveReload.

"But I've seen a how-to on setting up a Polymer application and they did mention LiveReload", you may say. Yes, people have demoed front-end tooling scenarios for Polymer, but apparently those scenarios are still in the "academic" phase...

Don't take my word for it, go ahead, try it for yourself.

So, should I use WebComponents & Polymer today?

I'm not saying you shouldn't. On the contrary. We need to move things forward; we need a better web, we desperately need better tools to build it and Polymer definitely has the potential to be a better tool. But don't let your excitement, the marketing hype or the tech buzz-of-the-day cloud your judgement. Make an informed decision and don't expect a silver bullet.

Personally, after two weeks of studying and playing around, I still have mixed feelings about it.
I'm not sure I'd use it for a public website with a wide, non tech-savvy audience.
But it does look like a safe bet for building a PhoneGap-packaged application for Android devices...

Final thoughts

Everything I wrote above is just a personal opinion regarding the practical state of things today, Feb 17th 2015, as I am evaluating Polymer as an alternative for a personal project. But technology is changing and evolving constantly, so make sure to draw your own conclusions.