Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override.

The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hatches, otherwise when you do hit an edgecase you get stuck with no solution. That's exactly what would force you to throw away that approach and pivot. Tailwind doesn't have that problem because it was designed to include escape hatches.

Users deciding to use those escape hatches instead of sticking to a design, isn't Tailwind's fault.

▲

nextaccountic an hour ago | parent [-]

It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way.

I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply

▲

francislavoie an hour ago | parent [-]

Using @apply defeats the entire purpose of Tailwind. The point of it is to localize styling alongside the markup. If you're using @apply then you're constantly context switching from your markup to your CSS files while working.

There's plenty of ways to manage the bevy of classes you need. First step is making use of components to deduplicate stuff. Then in those components, use a library like class-variance-authority aka "cva()" which allows you to set up complex named presets for your components (like size="small" or color="primary" and things like that).

	▲	woutr_be 43 minutes ago \| parent [-]
		I use @apply in quite a few projects, mainly because I like the defaults in tailwindcss. I know it defeats the point of tailwind, but I find that it works nicely when using BEM.