[manmal]

I think you are disregarding Tailwind‘s composability almost completely and still thinking in terms of the document based HTML/CSS model.

With TW, it’s preferable to reuse whole components (JS+HTML+CSS). So in your example, you‘d have a button React/Vue/LiveView/etc component that is reused across the app. Only if _that_ is not feasible, you should fall back on @apply.

If you’re developing in an environment where HTML+JS+CSS code reuse is not possible, then I agree that OOTB TailWind is not that much better. But for a component-based architecture where you want to minimize outside dependencies, TW is IMO ideal. Meaning: React, Vue, Svelte, Elixir Phoenix (incl LiveViews) and many others.

[wiredearp]

If Tailwind relies on classnames used in the HTML and defined in CSS, then that is the document based HTML/CSS model. The composability you are talking about is a feature of CSS, not the component framework. By stopping short at "utility classes" instead of "semantic" classes that define a complex appearance, you in fact destroy composability in favor of either inheritance (assuming that your component framework allows) or simple copy-pasting. Ironically, Tailwind does feature the concept of classnames that aggregate utility classes to produce a complex appearance, it is called "@layer components", and it is infinitely more composable because you can @apply these things as well.

.my-tab { @apply my-button bg-transparent; }

There is actually a very powerful CSS framework hidden in there somewhere, but they remain intent on appealing to developers who believe that real layout is coded with JavaScript, perhaps it is because Tailwind is a multi million dollar business that relies on selling components to teams that give up on making their own.

Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized). This shared dependency, or "global variables leaking into my scope" as programmers would phrase it, is the problem that CSS frameworks have been fighting for years, and now it's become a brilliant feature of Tailwind that components can share styles. Welcome to CSS! Now you only need to define your complex layouts via @apply and you can share them as well, that is what composability is all about.

[manmal]

> you in fact destroy composability in favor of either inheritance

I favour composition over inheritance, so I'm ok with that.

> Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized).

I think you just made the case for using vanilla Tailwind and restraining from customizations to cater to design extravaganza. The days of pixel perfectness are over, and designers can and should IMO get used to making compromises. Form follows function, and using vanilla TW can get you more "form" in the same amount of dev time.

Having said that, wouldn't you just have to merge the two Tailwind configs and generate a new CSS file? Apart from color naming clashes (which can't be avoided in any system) I don't see any issues there.