If I’m using React components, tailwind makes even less sense.
I’ve already separated my button large out as a component, guess what happens in a mature design system? The system gets updated and changed to fit the needs of the product.
So what happens when you need to change button large in tailwind? You need to restyle the button with the spaghetti mess (maybe add something to the config), then re-extract the mess into a tailwind component. Now you’ve got components within components just to emulate the abilities CSS has right out of the box.
Guess what you could have done? Just had a .btn-lg class in an old school style sheet where you updated to the new font weight and padding and you’re done!
There is no need for this layer of complexity and abstraction of CSS. CSS is literally the easiest thing in the entire stack. Why do you want to make it so complicated?
Rube Goldberg machines are extremely elegant in their beauty, but they are not the most efficient way to get something done.
I absolutely do have a .btn class in my Tailwind projects, that's a given. For consistency, it's built from the utility classes that Tailwind provides, but buttons are kind of a pathological case in many ways, they're really not how you should evaluate a framework. When I put two buttons next to each other, I don't make a new class for one of the to get some spacing, I just slap a "ml-4" on one of them, and that matches all my other spacings.
But the real magic is when I'm building up my mid-level components, I don't have to try to come up with names or abstractions for the CSS, I just make things look and work right, and as I notice patterns I can break them out into semantic classes as needed. It's a great way to work and the results have been good for me.
In my mind, the real mess is a bunch of poorly named CSS classes that end up being specific to the place where they're used. Specificity battles, 40 character BEM selectors, mismatched margins sizes and randomized colour palettes. Setting up a Tailwind configuration is a very ergonomic way of turning your basic design system into CSS.
In other wards instead of doing <button class=“btn-lg><button/> you're doing <Button {...specs}/>.
No, your designers should already be working to scales for size, colour etc. which you can implement in Tailwind. If they don't, now's a good time to start.
> How the hell does that help with consistency? You have to copy paste that mess every time you create a new button
You're extremely not supposed to copy-paste that. You're supposed to extract it somehow, either with your Javascript component framework, or by making a semantic class with the @apply directive.
https://tailwindcss.com/docs/extracting-components
The difference is that Tailwind allows you do some quick work without coming up with abstractions. So you work bottom up instead of top down.
> then guess what happens if the button you copied from needed special margin?
That's the beauty of it! You have a button class, and then if your button needs "a little extra" you add the button class and the margin utility.
At my previous job, when this situation came up, the normal way was to make a BEM class specific to the location, import the button in that (with a SCSS mix-in) and add the margin. So the HTML would have a class name that was specific to this one button, but you didn't know what it added: class="info-page__navigation__button". With Tailwind, you get 'class="btn mx-2"' and you can basically see what it's going to look like.