There are many, many, many cases where communication is not possible because who is working on the code now didn't exist when it was written (unless you want to take the time to document out all of your CSS and hope that everyone who touches it follows that documentation exactly). A new team taking over, a new agency updating a website for a client that was made by another agency, a new developer being brought on, etc.
Have you ever jumped in on a project with hundreds of "secondary sticky container hero-text" all over the code base? It is a woeful few hours (at least, maybe day or two) of cross-referencing all of these "semantic" class names to their definitions in CSS, and even then you are never truly sure if there is another rule overwriting your changes somewhere else in the CSS. And good luck if more than one developer has touched the code since you last saw it.
Oh the joys on having to edit a website that was made (by myself or someone else) years ago before Tailwind. It takes at least a few hours to figure out exactly what all these class names actually do, and you are still never sure that there isn't some random lines in the CSS files that will prevent the style from changing like you hoped.
I would love to see the CSS files behind your amazing Tailwind-free designs and know how easily a new dev/designer can jump in and make meaningful non-breaking changes. Especially if any of those projects have touched more than one team over a few years.
They discourage you from doing this wholesale for the good reasons in the link you posted. But it is still highly useful for small elements that are reused across the site.
Plus, I'd assume that almost everyone using Tailwind is going to break their website/app into reusable components - which negates the need to use @apply across the board.
You can quickly create a .primary-button (or whatever) class where you group all the Tailwind classes with an @apply. Then just add primary-button wherever you want.
I'd also add that the code in the Tailwind example is much easier to maintain and jump in on. It describes everything going on without you having to cross-reference a separate CSS doc with all of the actual meaning hidden in it. Joining a new project with 1000+ line CSS files + media queries randomly added throughout is a horrendous experience.
You can use CSS preprocessors such as Sass that have inheritance. But most people doing front end design these days separate out design elements into components, which pretty much completely handles the re-usability of the underlying CSS. But @apply is useful for smaller elements used across components like buttons, form elements, headings, etc.
I've been using Porkbun for years and it's been great. Good prices, reliability, security, and they don't push nonsense add-on services on you like a lot of other domain providers.
Until a better library comes out, I'd highly recommend using Layercake with Sveltekit. It's a wrapper around D3 which allows you to build reusable components that are responsive and can load server side without JS on the client. It's not as plug and play as some libraries, but it's not too bad, and gives you a lot more customization options:
