What does Polymer bring to the table?

jochemstoel profile image Jochem Stoel ・1 min read

Forgive my ignorance

I was reading the quick start tour of Polymer and at first sight I can't really identify any new functionality or added value. Is it supposed to simplify something?

In your own words, what exactly does Polymer bring to the table here that we can not already do by registering custom elements with the available APIs?


markdown guide

Think like this, React done by google engineers in a googley way. Thats polymer.


This is not any type of answer to my question.


Both are based on concept called Components.

When Facebook did it, they named it React

When Google developed component based JS library, they named it Polymer

I thought Google developed Angular ...

Google developed a lot of other stuff besides Angular, like Polymer, Flutter, Golang, Dart(?), and AMP.


Well, have you ever tried to build a web component with nothing but the APIs that were proposed as browser standard and are (maybe with the exception of HTML imports), rolled out across the major browsers, i.e. custom elements, HTML templates, Shadow DOM and HTML imports?

I did that as an experiment once, and came to the conclusion that what can be considered well-supported is technically enough, but it's rather inconvenient to build actually useful things with. I was very much concerned with low level plumbing stuff and found the outcome to be something which I would not like to do on a major scale or maintain in the long run.

There have been several attempts to provide more convenient abstractions to build web components. Polymer was a rather early attempt. Competitors are e.g. x-tags, svelte, StencilJS, and relatively recent, Angular Elements. Out of them I've worked only with Stencil and Angular Elements, so I can't tell you how much convenience Polymer really puts on the table, at the very least, the templating and data binding seems to be half-way decent.

The promise of web components is sharing framework agnostic widgets. I.e. you don't have a vendor lock-in as a user of the component, and can mix and match components from different sources, you can do plain JS or combine it with a framework. In theory at least.

I think Google backed/backs Polymer because it fits nicely into its strategy of pushing Progessive Web Apps and the web as application platform in general.


Might not answer your question but we're working quite a lot with polymer at my workplace, and there's one thing we could notice: The polymer technical docs are pretty much lying.

A lot of things are said and explained, and while digging into its core, or trying to push its limits, you 'll spend more time fighting the docs than actually reading the source code of Polymer itself, to understand how it works and can be used.

For a "professional" tool, we've seen better.


Disclaimer: have never used or read that far into polymer.
Taking a look at an excerpt from the feature overview page:
"The Polymer library provides a set of features for creating custom elements. These features are designed to make it easier and faster to make custom elements that work like standard DOM elements."
It sounds to me like it just enhances ease of development and code reusability.
If i'm wrong, somebody, please let me know.


Their aim is to not be needed one day, it's just a lot of polyfills making Custom Elements work across all browsers cough not IE cough.
Of course, there are also a few tweaks and changes to make easier for developers that aren't in the platform but not too many.