Most UI kits let you pass any style as a prop — radius, size, color, or a wall of Tailwind classes, whatever you need. That flexibility is exactly the problem: it turns every component call into a one-off styling decision, and no two buttons end up the same. Let's talk about practices that prevent building an inconsistent, unmaintainable code base that won't scale.
Tailwind class soup is something I see often in LLM-generated code. For some reason, every starter template in existence decided to include Tailwind, and then the coworker generating this code (who doesn’t have frontend experience at all) just rolls with whatever the LLM shits out.
I believe there’s a proper way to use Tailwind, but I can’t be bothered to read the docs for it. It makes far more sense to me to either use plain CSS or, if I’m using a component library, then whatever that library comes with for its theming system.
Also, this whole article basically boils down to “use a proper theming system”, which it even admits can be as simple as some CSS classes with standardized names.
Eh, if you’re using React or any other modern app framework (or “library” as they call themselves) then Tailwind classes are nicer for co-locating styles with their respective components. Vue lets you co-locate the actual style block, but even that’s not as nice as seeing the styles directly on the elements themselves. There are still uses for global-level CSS of course, but there’s no “central” place for those besides the html tag.