[chrismorgan]

Custom Elements is the low-level API that allows you to do all kinds of things.

Polymer is designed to sit on top of that as a higher-level API.

This is how things should be. Otherwise you get designed into an undesirable corner. (Example: I can imagine improvements to the Polymer code achieved with decorators and TypeScript, for example, which would require a somewhat different API. To need a translation layer over that for evermore is undesirable.)

[jarym]

I seem to recall IndexedDB was designed with the same thinking and that hasn't worked out so well.

(Not talking about Custom Elements here since I don't know enough about it - the comment is levelled at the process).

It's all too easy for people in a committee to manufacture the idea of some mythical figures further along the conveyer belt who will magically make something useful out of a giant specification with gaping holes.

[reificator]

Polymer was released and worked on as a library while the spec was being worked on. Polymer 0.x and 1.x targeted a version that was only implemented in Chrome, which was used to build the eventual standard, and Polymer 2.x targets the final standard.

The API for web components isn't that bad. You have to stamp DOM templates yourself using whatever process, you have to handle attributes and properties yourself, and that's about it. Lots of boilerplate, but a library like Polymer can take a simple, opinionated approach to handle it for you.

From my experience Web Components have been pretty pleasant to use with or without Polymer, it's just a matter of wiring everything up if you go vanilla.

[dmitriid]

> The API for web components isn't that bad.

> Lots of boilerplate

If there's lots of boilerplate, the API is bad.

[reificator]

ServiceWorker vs Application Cache, I'll take ServiceWorker every time.

When you're talking about a low level primitive, boilerplate is preferable. It means you have options. You can throw Polymer or any other library on top and get what you want out of the standard, while someone else can come with different requirements and not be boxed in by your own.

If you can distill your argument to one sentence, it probably isn't blindly applicable to all circumstances. Yes that was one sentence.

[dmitriid]

DOM APIs (which Custom Elements are) are not really "low-level". They are low-level in the sense that they are cumbersome imperative boilerplate compared to basically anything else on the platform.

The main problem with boilerplate in DOM APIs is not that they are "low-level". It's that w3c never makes any effort to address the developer experience when using these APIs.

This is why you end up writing 10 lines of code just to sync properties and attributes in Custom Elements where a single `{reflectToAttributes: true}` would suffice and remain low-level.

This is the problem across the board, not just Custom Elements. The goal of a platform (and the web is a platform) isn't just to provide cumbersome low-level APIs, but also a set of sane defaults and a set of APIs that address the majority of a developer's needs. w3c can barely provide the former, and has never been able to provide the latter.

[chrismorgan]

Polymer in particular has been actively involved in the shaping of Custom Elements, so I believe we’re avoiding that issue with Custom Elements.

[dmitriid]

Riight. What you're saying is: "we must have horrible imperative code that takes three times as much code as a simple declarative/fluent API because ... reasons".

There's next to zero requirements for "static get observableAttributes" and "attributeChangedCalback" which in 99% of the cases can easily be replaced with

   static get properties() {
       return {
         x: {reflectToAttribute: true}
       }
   }

etc.