[mintone]

If you're not using components (react/vue etc.) then you can use @apply - I think the secret with that is to blend inline tailwind and the applied style so you might say..

.button { @apply rounded-md bg-gray-600 hover:bg-gray-300 text-white; } and then inline you might use class="button px-2 py-4" or similar to create specific styles. Of course these could be abstracted again to .big-button .small-button etc.

Tailwind has changed not only how I write CSS but how I think about writing front-end code completely - it's really great once it clicks.

[kall]

I like tailwind a lot but that style of using @apply smells exactly like creating ad-hoc css classes to me

[rvense]

How is it ad hoc? You're creating a class .button, but you're using the Tailwind-specified design system. This is how the framework is meant to be used!

Atomic/utility-first CSS doesn't mean that you shouldn't make classes. It just means that you should make them where they make sense. Don't make a new class just to add a margin to something,or whatever. If the margin is literally all this element needs, use the utility class directly. If it's the only place you'll use this combination of classes and naming the combination doesn't add anything, you might as well just keep it inline.

But if you find yourself repeating a bunch of utility classes, make a class with a semantic name once you start seeing the pattern. In some cases, like buttons, you might see that pattern before you've even started. That's fine. You should definitely have a button class (or three).

What you (probably) shouldn't have a is .info-page__navigation__aside__second_button that just includes the button class and adds a margin, or whatever... like we did at my old job. Urgh. I refer to this as "might as well be inline CSS" - making extremely specific classes that are only used once. If your CSS classes aren't reusable, all you gain from not having it inline is the joy of maintaining two text files, and manually look up the cross references. Tailwind solves this perfect, IME.

[kall]

To me, that is what it means: You shouldn‘t make classes.

Only if you are using a component framework or something that works like it though. Otherwise you should make semantic-style classes, yeah.

It‘s ad-hoc because you can not predict what a class contains (tailwind classes) or how it is spread through your codebase (BEM classes)

[rvense]

Not everything requires making a component. A CSS class can be fine, and I'd always use the least powerful way first. This is how the framework is meant to be used - that's the entire reason for having @apply.

https://tailwindcss.com/docs/extracting-components

I don't understand what you mean by ad hoc. It's a very structured approach. When utility classes don't work, you make a semantic class. If that doesn't work, you make a component. You can even use BEM naming if you want, you'll just be making a lot fewer classes.