[troupo]

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

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]

I'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]

google "html web components"

[troupo]

It's a nonsensical term for components with predefined markup and no Shadow DOM

[jamiedumont]

So 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]

JS/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]

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

[jamiedumont]

They still rely on JS to instantiate though unless I've misinterpreted?

[gryzzly]

the 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]

> so client-side stuff kicks in only when it can and needs to be kicked in.

All web components are rendered eagerly, so it kicks in immediately the moment it appears on the page.

[gryzzly]

No, it appears on the page = HTML and CSS is parsed. When you load your scripts is up to you.