3 ms·
Yeah, it isn't Tailwind that doesn't support web components. It's Shadow DOM that is such a bad abstraction that it breaks the web in innumerable ways and need
by troupo 3y ago
Yeah, it isn't Tailwind that doesn't support web components. It's Shadow DOM that is such a bad abstraction that it breaks the web in innumerable ways and need dozens of new standards to fix its shortcomings.[1]
And yeah. That <fancy-component> that is seemingly not an eyesore? It's not because Tailwind is bad and "pollutes HTML". It's because web components hide any and all ugliness from you so that you can pretend they are beautiful.
Because in the end there's literally nothing on the web but divs and spans
[1] From web component report by people making them: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
- jamiedumont 3y agoI'd like to like web components, but their reliance on JS to instantiate along with all the chaos of the shadow DOM keep them off the table for me. I think they are a great concept defeated by the implementation.
- gryzzly 3y agogoogle "html web components"
- jamiedumont 3y agoThey still rely on JS to instantiate though unless I've misinterpreted?
- gryzzly 3y agothe point of them is that you are providing full proper HTML and CSS so client-side stuff kicks in only when it can and needs to be kicked in.
- troupo 3y agoIt's a nonsensical term for components with predefined markup and no Shadow DOM
- jamiedumont 3y agoSo essentially what partials in a template or server-side include solve. That's the only "build-like" part of my current website, but I'd much rather manage this beforehand and serve static HTML, or run a server-side process than use JS/HTML web components at runtime.
- gryzzly 3y agoJS/HTML web components are the static HTML – ``` <marker-of-dynamic-behavior> {your standard static html} </marker-of-dynamic-behavior> ``` This is just a better way of doing DOM scripting, enhancing without waiting for Document Ready event, and having more freedom when to load the dynamic bits.
- troupo 3y ago> This is just a better way of doing DOM scripting Better than what? > enhancing without waiting for Document Ready event Instead you wait for `connectedCallback` > and having more freedom when to load the dynamic bits. You literally have no freedom over that. Web components are rendered the moment they are added to the page, and you have no control over that. So if something dynamic is happening in your `connectedCallback`, boom, our dynamic bits are loaded whether you want them or not.
- gryzzly 3y agobetter than centralized `$('.special-element').applyDynamicBehaviour()` you control when the script is loaded right? connectedCallback happens per component, not in a centralised manner – so you write the logic for what happens in a place where it happens