webcomponents

dules out the door since its been eight years. https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

spec so that the actual useful specs like Scoped CSS have to be delayed almost indefinitely to try and figure out how to work with this abomination of a design To quote the report linked above, "many of these pain points are directly related to Shadow DOM's encapsulation" - The amount of specs that are required to make them work, barely, and be "good web citizens". And the amount of APIs. Oh, you want your custom input to a) be able to send its data in a form, and b) be accessible to a label outside of your component? Well, there's a separate API for a) and there's some separate future API for b). And meanwhile your custom button won't be able to submit your form, sorry, it's a 4-year old issue with no solution: https://github.com/WICG/webcomponents/issues/814 And all that despite the fact that there are already a dozen specs covering web components, and dozens more on their way. - Web Components ar HTMLElement. It means you cannot use them inside SVGs. This is impossible: <svg> <x-axis min="2000" max="2019"/> <y-axis min="0" max="100"/> <scatter-plot points="..."/> </svg> This makes them unsuitable to a huge swath of graphics- and visualisation-related applications. - A smattering of other issues: -- They cannot be easily used when progressive enhancement is required: SSR story is still non-existent, you can't easily update the original DOM in a custom element without trashing it. -- They cannot be easily lazy-loaded because slotted content is eagerly loaded: <p>Toggle the section for more info:</p> <toggled-section> <html-include src="./more-info.html"/> </toggled-section> `html-include` will load in its entirety even if you never toggle the section. And yes, this causes a cascading loading of multiple resources, too. -- they share a flat global namespace. Of course this will be solved in the next five years by a yet another spec. -------------- If any userland framework had these many issues, it would be laughed out of the room. And yet here we are with people trying to argue that they are good now actually and all that stops them from being used is "connectedCallback" name. These are also the reason why most framework authors that initially supported web components (Vue, Svelte, Solid) are now at best completely indifferent towards them.

people behind web components listened to anyone except themselves.

know it, that gives them the top-down predictable well-ordered machine feel that writing a main() function has. The possibility, of so much, scares the programming tradition. I really hope something good comes from this. Alas it's still kind of a PITA that WebComponents don't have a transport layer that makes sense. We'd hoped to de-bundle and be able to use HTTP Push to speed module delivery. We'd hoped we'd have module registries, a "post 1.0" effort for es2015 modules, but that never happened- we got other things instead, import-maps, import.meta, others... but figuring out how to effectively deliver a modular new thing that multiple sites can use on the web is still also another layer of unsuccess, another dimensions of modularity that never really emerged. Great post by Lea, good initiative, and hpoeful we can start re-weaving & connecting together the web, after Shadow DOM broke us into smaller pieces. --- semi-related, there's some interesting discussion on how some spec-authors intended/expected WebComponents to be adopted versus how they have. i'm still not sure how this addresses a lot of the concerns here, but it's an interesting discussion. and i like a lot of how it suggests that the Shadow DOM is for decoration, but that it ought have a visible apparent part to itself too, not be so isolating. this comment & @domenics follow up are both semi-interesting... but i think are also very due for a longer treatment/write-up. https://github.com/WICG/webcomponents/issues/986#issuecommen...