undefined | Better HN

0 pointsreificator8y ago0 comments

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.

0 comments

dmitriid8y ago

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

> Lots of boilerplate

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

reificatorOP8y ago

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.

dmitriid8y ago

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.

j / k navigate · click thread line to collapse

0 comments

dmitriid8y ago

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

> Lots of boilerplate

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

reificatorOP8y ago

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

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

dmitriid8y ago

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.

j / k navigate · click thread line to collapse