No. Adam said multiple times that he basically added the feature to make onboarding people smoother.
The right way to use Tailwind is to extract components, for example in Vue.
That way you have the markup, behavior, and styling in self-contained in a single file, that can be used anywhere, without leaking any internal implementation details.
If you extract components then you require JS (low lighthouse score, lots of JS processing on slow devices, likely SEO problems) or SSR to render the page and then serve it (high TTFB)
Ideally you would have some kind of build step that can pre-process all the vue components and spit out pre-rendered HTML for all pages but preserve the interactive parts of the component scripts.
Only for interactive components. You can use PHP or a static site generator and create components with no runtime JS at all.
That's not the full story. Using @apply is the only option if you're not using a component based JS framework like Vue or React.
@aply works everywhere. The current documentation highlights this difference; showing both component extraction and using @apply as a failback when you want to go old school.
But the right/ideal way to use Tailwind is to use components. That way you get the most dev ex that Tailwind can provide.
@apply bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded;
so @mixin in Sass? @apply in CSS? (being replaced with Shadow Parts)If only CSS had thought to include such a feature.
The utility classes are in themselves great. It's a complete set but it still promotes thinking in design systems.
CSS classes are good, but should be used in moderation. Since you're likely using a component framework anyway, you can often just use the utility classes directly in your components with no loss of clarity and without repeating yourself. But when you do end up repeating yourself in the CSS, you can reach for postcss's @apply and have access to Tailwind's design system. The three levels work extremely well together.
The moment you collapse the classes in to a single class you're back to square one and the reason functional CSS arose be first place.
Adam Wathan promotes this pattern himself in this video.
You can also apply configuration changes globally that might affect multiple properties. If you're changing from px to rem for sizing, you can do that without having to go through your entire code base to update that. Or if you need to tweak a color, it's applied everywhere, including computed values (color variants).
It lets you move all of those excessive class attributes into your CSS, where it realistically belongs. And that makes your CSS look a little more like CSS. But you get guard rails on it by applying a known set of properties to each rule. It's really the best of all worlds.