Components with extensibility through inheritance written in a prototype-based language. Having worked with around a dozen component-based systems over the years I'm not particularly enthusiastic.
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>
It would be even better if people working on these specs spent some time reading research papers on how a sane component-based system could work. For example: http://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.ht... A lot of interesting ideas regarding extensible behaviors and ease of understanding.
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.
> It would be even better if people working on these specs spent some time reading research papers on how a sane component-based system could work.
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.
It's true that I don't know for sure, but I haven't seen any citations, or verbal references, or any similarities in the APIs that would indicate familiarity with the relevant research I had in mind.
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".
By working in practice I don't mean "unimplementable or not", I mean the difference between CORBA and gRPC: One can argue endlessly about the benefits of one vs the other, but it's practical experience what's informed the latter of how and why the former sucked.
> 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.
Excellent tutorial, as usual from Eric Bidelman. It's a lot of information to digest though, one should take time with all the different bits and pieces covered in this article.
(It still needs some more convenient ways of defining the graph structure, as well as an interface to do force layouts.)
I haven't worked on either project in a while. I kinda got tired working with the development version of skate.js while the custom elements spec was changing so fast. It's an excellent library, but things were moving too quickly for me to keep up.
Today, I'd probably just do it in plain javascript, since the spec is more stable now.
You can emit normal events (they bubble up normally), you can use a notification bus, redux, whatever you want. And your elements are visible in DOM normally like all other elements.
We've been using Web Components + Virtual DOM to build our web apps for the last year at Mixpanel: https://github.com/mixpanel/panel. The biggest issues have been dealing with polyfill issues (especially Shadow DOM leakage) and versioning elements (given the global namespace issue of "registerElement")
please correct me if I'm wrong but it seems that custom elements still do nothing about dependency hell (it's not possible to use same lib in different versions)
Basically, it's about "we can't use lib x because it will break lib y" - this already happens in java and I would consider java being very conservative and slow-progressing.
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)
It's one of the biggest problems in fronted development right now and it's something conceivably can be addressed by the... well, let's call it "guiding structural paradigm" for the lack of a less pretentious term.
I don't know, in my frontend experience dependency hell is less about conflicting dependencies and more about literally installing 690 packages after one `npm install <package>`.
Fixes need to happen in the broader npm ecosystem, not the standard for creating reusable components.
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.)
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.
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.
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.
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.
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
Your comment is unnecessarily snide / cynical; you should be aware that the Polymer team is the main driver of the Custom Elements committee. Polymer 2 is now a framework on top of the Custom Elements standard they helped develop and flesh out with Polymer 1.
Your comment basically reads like "Polymer team made sure the API is horrible so that everyone would flock to Polymer when looking for better/saner ways to deal with WebComponents"
Apart from what others have mentioned about how the Polymer team contributes to the standard, as someone who's worked with Polymer, I think you're also painting a far too rose picture of Polymer, unfortunately.
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.
It would be even better if people working on these specs spent some time reading research papers on how a sane component-based system could work. For example: http://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.ht... A lot of interesting ideas regarding extensible behaviors and ease of understanding.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/...
https://github.com/microo8/golymer
This piano keyboard element: https://micahscopes.github.io/all-around-keyboard/
Some elements for quickly drawing graphs in html: https://micahscopes.github.io/tangled-web-components/example...
(It still needs some more convenient ways of defining the graph structure, as well as an interface to do force layouts.)
I haven't worked on either project in a while. I kinda got tired working with the development version of skate.js while the custom elements spec was changing so fast. It's an excellent library, but things were moving too quickly for me to keep up.
Today, I'd probably just do it in plain javascript, since the spec is more stable now.
<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)
Fixes need to happen in the broader npm ecosystem, not the standard for creating reusable components.
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
etc.