[SebastianKra]

Decent arguments. Ultimately, I think your preference comes down to:

- Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like. Web standards will always be slower to evolve, which is why we build tooling on top.

- How do you think web components will be used? - I believe they will be used sparsely, only by libraries. But if you want to replace your frontend framework (I currently don't see why), Tailwind will not work.

We've opted to work with CSS Modules (which give you many of the Shadow-DOM advantages), but I would be lying if I didn't see the appeal of Tailwind every day. For me, it's the redundancy of having to give semantic names to elements that are already described by their React component names.

Tangentially, developers often are tempted to use classes for things that should be components. CSS classes must not be used for code reuse on a large scale, because CSS and HTML are bidirectionally coupled and you will end up search-replacing large sections of html because the design team wanted the text to align in a way that is somehow impossible without adding a div.

[PrimeMcFly]

> Web standards will always be slower, which is why we build tooling on top.

I don't follow. I don't see how frameworks or tools have anything to do with standards being slow.

[SebastianKra]

* Slow to evolve

As in: it took years to get something thats even remotely comparable to framework components. Tooling can move fast and course correct, the standards have to get things right the first time.

[PrimeMcFly]

I still don't see the relationship. Framework components are using the standard to create what they create, and that's how it's meant to be.

I wouldn't expect the standard to ever really offer most of what a framework does.

[lawn]

> Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like.

It's not a good comparison. You won't ever read the output of your Weboack bundle, but you will surely read the html you write (or worse, is tasked to modify or debug).

[timeon]

also:

- Do you care for bloat user needs to download?

[troupo]

If you're already using a build system, then throw in Tailwind pre-processors, and you will ship only the classes and styles that are actually used on your site.

Unlike, say, Youtube which ships 2.74 megabytes of css. With amazing non-compressable unique names like .`yt-mini-app-container-view-model__loading-icon-animation` and `.yt-spec-button-shape-next--size-l.yt-spec-button-shape-next--icon-button.yt-spec-button-shape-next--segmented-end`.

And re-inventing utility classes, badly:

   .yt-spec-button-shape-next--size-xl .yt-spec-button-shape-next__icon{width:24px;height:24px}

    .yt-spec-button-shape-next--size-l .yt-spec-button-shape-next__icon{width:24px;height:24px}

    .yt-spec-button-shape-next--size-m .yt-spec-button-shape-next__icon{width:24px;height:24px}

    .yt-spec-avatar-shape__button--button-extra-small{width:24px;height:24px}

    etc.

And Youtube is just an example of a symptomatic issue: everywhere CSS ends up growing beyond anything reasonable, with multiple repeated and duplicated styles that everyone is afraid to touch.

Tailwind helps with this a bit: there's a fixed number of utility classes, you're supposed to use them inside components (so they are collocated, but unlike CSS-in-JS you don't write what are essentially inline styles, but chose from a fixed set of classes), and only those needed are shipped.

[theshrike79]

If your web page is so efficiently managed that the amount of CSS Tailwind adds is "bloat", I envy you =)