My opinion on the Polymer library

September 16, 2016 by Christoff Truter JavaScript   Opinion  

From time to time we are forced (for whatever reason) to use technologies that we don't agree with (just to set the tone of the post), a recent example from my own experience is the Polymer library.

Never heard of it? Not surprised, adoption by developers over the last few years proved to be rather dismal (but hey, perhaps 2.0 is the lucky number?).

What is Polymer exactly?

Well, at first glance I thought it had something to do with molecular chemistry.



Hmmm, Md (Paper aka Material Design elements) 1.0.6, well. paper isn't exactly an element, you do however get a radioactive element called Mendelevium (Md) with an atomic number of 101 (ironically its currently only used for non-commercial research purposes).



At a stage (after butchering away through extremely poorly documented ill designed web components) I was honestly starting to believe that Polymer might be a cruel social experiment conducted by Google.



After a while I was convinced that management was testing us - will we use whatever they give us regardless of how ridiculous the technology might be, without question?

All jokes aside, Polymer is basically an early adopter of the emerging web components specifications (custom elements, html imports, templates and shadow DOM).

Currently only the latest versions of Chrome and Opera fully support these specifications (Firefox requires the enabling of a webcomponents flag).



To circumvent this limitation, developers created a suite of polyfills, thereby faking support for web components for the various browsers.

This is one of the major crutches pulling Polymer down, plagued by slow loading times and memory leaks in Internet Explorer.

See:
Memory Leak in IE11 even after refreshing the whole page.
Polymer will lead to memory leaks in Internet Explorer 11.



Now we can blame internet explorer (and ignore other frameworks on which developers painstakingly spent countless hours to add support for IE), display a 90's style message on our website (works best in Chrome, using 640x480) or just turn a blind eye on issues.

Seeing that this issue was first reported around February of this year, either the Polymer team doesn't have enough time to solve this issue, don't know how to solve the problem, or they're ignoring the problem (from a production point of view this doesn't bode well).



I do however get that Internet Explorer is reaching end of life, but is it acceptable to ignore technical challenges, just for the sake of being able to use web components today (before its fully cooked), alienating potential customers simply because we all know Internet Explorer sucks?

What can Polymer currently bring to the table (practicality wise) that we don't already have? In what way will any of this make anyone's lives any easier?

Now don't get me wrong, I agree that we need bleeding edge technologies like Polymer to evolve the web, without them we would probably still be stuck using Java applets and framesets.

But is it sensible to build your multi million dollar project using a technology built on top of a "force ripe" web component implementation?

Additionally if you're going to buy into Polymer, you must logically also buy into its philosophy (Which kinda reads like a weird hipster statement of faith - phrases like "We Believe" and "The Platform" which is essentially just vanilla javascript, "What we deserve" - straight out of a batman movie).

It all boils down to relying less on frameworks and more on what the native platform provides us - treating the platform as the framework - going bareback.

Is it really sensible / possible to treat "the platform" as a framework? But then again, is that honestly really something Polymer is achieving?

Simply stating #UseThePlatform, doesn't make Polymer immune against cross platform issues etc, we still need to include crutch libraries (aka shims) to compensate for holes in "the platform", ending up writing a framework either way - to avoid bloat you will ultimately need to include more bloat.

If we truly follow the bareback approach, we might find ourselves re-fixing problems that we already fixed a decade ago, due to the fact that we're trying to trust "the platform".

Conclusion

Critical issues left open for months, some even years, would you consider this enterprise acceptable?
(Some issues closed due to frivolous reasoning - e.g. perhaps someone fixed it by now)

You end up spending more time fixing your tools, than solving problems with those tools.

In my opinion the "elements" (Polymer webcomponents) aren't production ready, which means you end up with a bunch of cripple webcomponents, point and case Polymer's material implementation (paper-elements), basic functionality like validators are for lack of a better word, half-assed (considering Polymer is more than 2 years old already, basic issues should have been sorted out by now).

The recent removal of expressions and filters from data bindings in Polymer (apparently in the name of performance), cripples it even further.

Since Polymer isn't a full fledged framework, it needs to be used in conjunction with a proper framework. But why would you want to? What can Polymer give you that e.g. Angular directives can't?

All things considered, I currently find it very difficult to see any real intrinsic value to using Polymer.

Moving Forward

I am going to keep an eye on Polymer and play around with it in my research projects (treat it like Mendelevium), but for the time being I am going to avoid using it in a production environment.

At the end of the day I appreciate that the Polymer guys (and girls) are trying to build a better web, but I think we met too young

Additional Reading

Polymer Project (Home Page)
Web Components (Wikipedia)
WebComponets.org