Custom Elements v1: Reusable Web Components
developers.google.com
developers.google.com
I think it would be much better for the web if browsers had a sane API for extending behaviors of any tag via attributes. This would make things easily composable and eliminate most problems of traditional component-based systems.
<button does-stuff does-more-stuff></button>
Edit: And yes, I'm aware of is="" functionality. It's not exactly what I'm talking about. In fact, if the specs were designed the way I mentioned, there would be no need for making anything special for built-in elements as opposed to the new ones.
I don't know the people working on these specs, but presuming that they aren't aware of research in the area, and moreover of what has worked in practice and what hasn't, is audacious.
Also, a lot of research in this field is done through working proof-of-concept systems, so there is no point in implying that those designs don't work "in practice".
[1]: https://github.com/google/WebFundamentals/commits/master/src...
> At time of writing, no browser has implemented customized built-in elements. Chrome plans to implement them (status) but other browsers have expressed distaste for implementing the is="" syntax.
I would love to just be able to "fix" the normalization around several built-in elements.
But there's a polyfill, and more discussion here:
https://developers.google.com/web/fundamentals/architecture/...
<my-container> <some-child some-attr></some-child> </my-container>
How can I get notifications in my-container when someone from outside adds another child to it?
You can get notifications through the mutation observer API: https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
[1] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
Now just have to wait a few years to be able to use it, or hope the polyfills actually cover all the browsers versions we might need to target.
Fixes need to happen in the broader npm ecosystem, not the standard for creating reusable components.
Now, imagine how quickly is javascript evolving, libraries, frameworks, etc.
Solution to dependency hell is a major reason why node.js succeeded (along with browserify/webpack) unlike anything with flat dependencies (bower)
Polymer. Designed by people who actually do web development: https://pbs.twimg.com/media/DALwpYWVoAAIvkQ.jpg
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.)
(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.
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.
> Lots of boilerplate
If there's lots of boilerplate, the API is bad.
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.
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.
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}
}
}