[Griever]

I’m a strong advocate for Tailwind, and I believe that this approach is truly effective. In my experience, this subset of Tailwind has been sufficient for every project I've worked on that used it. Moreover, I've observed that it often converts skeptics into supporters.

[krsdcbl]

Curious about your expectations: Do you rely on utility classes only in your workflow, or do you split reusable patterns into "original CSS"-like @apply blocks?

And how would you categorise the complexity of the Apps/UIs you build like this?

I'm very interested in the specifics of successful applications of Tailwind that the maintainers keep deeming a good solution, since CSS as a whole is one of my main scopes and I've had quite some projects that where basically some variation of writing custom brand-lib frameworks for teams who embraced Tailwind at first, but in time ended up hard locked when needing to refactor or iterate their UI

[Griever]

Great question. We rarely rely on shared utility classes these days. Historically we'd end up going the @apply route, but lately we just add a new style to the root-level css file and call it a day. We may prefix it with "@layer" so that it gets tree-shaken, but that's about it.

I've found that in component-driven UI, the need for these kinds of utility classes becomes less and less necessary. The utility CSS may be defined in the component, and the component is ultimately what gets reused.

Could you elaborate more on the reason for your interest? I've used Tailwind to implement several well-defined design languages, and always had great success. In fact, compared to other design systems, Material for example, I found it to be far simpler to manage over time.