It's a fairly limited set of rules that are mostly consistent, extensively documented, and easy to remember. But yeah, a little bit of effort is required when dealing with a styling language with over 300 properties.
Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun.
No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.
> Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon
I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?
This isn't about decision paralysis, but picking good names that other people will understand. But they won't, not all of them at least. No matter how great you're at naming things, you are going to do it differently than other people do. That doesn't matter on your personal home page, but it breaks down with a larger team. Inevitably, naming principles will drift apart, and after a few years, you'll have a mess. Don't believe me? Read the myriad of blog posts of development teams coming up with new CSS frameworks or migrating from one to another, to combat this.
Tailwind removes the naming ambiguity here, by moving away from naming things to describing the styles in a composable way. Drop your new hire in the code base, give them access to the Tailwind docs, and they'll be productive immediately (even more so if they previously spent half an hour with it).
The design just got a makeover, and you’re tasked with updating all buttons to have a wider spacing.
Good luck catching everything, including this class and its usages, without manually reviewing everything that is used like a button, inspecting the HTML, then going over the classes, one by one, without breaking some unintended side effect.
When you label something the implicit purpose is that it is now reusable. But an InnerWrapper class defined within a React component should be private and not actually reused, whether you are using global styles or css in JS (because it should be a private implementation detail—otherwise the component consumer has to also figure out the classes to apply).
> When you label something the implicit purpose is that it is now reusable.
What makes you think that? I wouldn't use a wrapper element from a different component in another component. At some point you just have to use common sense.
Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun.
No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.