I embrace the mess of tailwind-cluttered markup to eliminate context switching and save up some cognitive load.
My experience has been increased cognitive load when I come back to tailwind styles after a long time, when compared to dealing with handwritten CSS selectors and classes
Tailwind is only useful if you have some kind of templating system where you can define components. And in this case, it’s very easy to scope your css.
When you say "handwritten CSS selectors and classes," what you really mean is learning a unique codebase with high levels of abstraction that map on to the DOM in a structured way that cannot be automatically inferred. It has to be learned by looking at both the CSS (often buried in many component files) and how the components are implemented in the DOM. In large projects, this is far from trivial.
And I think that's the key. When people say "handwritten" CSS is either, what they mean is that their small project, with no other contributors, is easier to manage.
When picking up a Tailwind project, what's to learn again? You might forget some of the class names, but if you already know the CSS properties, you're 80% there. With your IDE's completion, you're 90%. And crucially, no context switching whatsoever.
Turns out HTML size also increase by 7-20x in tailwind CSS.
Tailwind CSS is "write-only" code. Maintaining a site developed by someone else who has gone full-blown worship of the Tailwind Dao is a nightmare.
Look, it's strictly pragmatic approach, i end up creating utility classes anyway and i'm really glad someone did this for me.
Maintaining Tailwind (or a mix of Tailwind and CSS) is routine, just like it should be.
And i'm talking about web app development, markup is cluttered anyway (tsx or whatnot), semantic effort is already put in components and such. So yeah, saving some cognitive load works and helps in case of Tailwind.