I don't understand when people see Tailwind as anything other than a syntax for CSS.
> forget all about the relations of styling rules to eachother
This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.
I'm not necessarily arguing in favor of deep cascading, but I don't see how something like this:
.form-element,
.button {
height: 32px;
}
Is something that can be easily achieved with Tailwind without either using @apply all over the place, effectively now doing regular old CSS but with Tailwind syntax, or by using JS/TS variables extensively making the styling pretty hard to read. Either way, I'm not saying Tailwind makes it impossible, but it sure doesn't make it easier. And while Tailwind has a bunch of benefits, especially where it becomes a design system rather than a syntax for CSS, you can achieve ~90% of that by just defining a bunch of color and size variables at the root of your CSS and using that.
I don't mind Tailwind too much for 1:1 mapping with DOM elements, but I also don't really see why inline styles for that case would be bad.
> Is something that can be easily achieved with Tailwind without either using @apply all over the place, effectively now doing regular old CSS but with Tailwind syntax, or by using JS/TS variables extensively making the styling pretty hard to read.
And use that component everywhere and the styles carry through:
<MyButton MyButtonText="Click here!" />
People worry about regurgitating the same CSS with Tailwind, while continuing to regurgitate the same HTML structures all over the place. Encouraging inline styling encourages you to stop repeating your HTML, which is a better approach, even for a design system.
The equivalent tailwind is to just put h-8 (or whatever it is) on whichever form elements and buttons you want to be that height. Tailwind recommends you never use `@apply` - it’s basically an escape hatch for weird, niche interop requirements if you’re not all-in on Tailwind.
What is it about your example that the tailwind approach (h-8) doesn’t achieve?
Tailwind's default sizes add constraints, which makes Tailwind a bit of a design system. Also, Tailwind's default colors are just very pleasant to work with. Even on projects where I don't use Tailwind, I look up the color table in the docs.
Same, I really have nothing bad to say about the Tailwind design system.
I suspect there is a lot of halo effect going on, where if people were asked to judge the pure code aspect of Tailwind vs the design system separately, they'd be much more negative on the code aspect of it, but because the two are conflated and one is very good, Tailwind as a whole is judged to be much better than I personally think it deserved to be. It doesn't help either that forming an opinion on an architecture of code is difficult, and forming an opinion on a designed web page in front of you is easy.
My personal poison is just defining the Tailwind color system and a very basic system of sizes in CSS variables and then using that all over the place. It leaves an escape hatch in place of just using 5px when you really need to, but most of the time we use var(--col-grey-200) and var(--u-4) or var(--u-8)
> forget all about the relations of styling rules to eachother
This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.