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.
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.
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}
}
}