> If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.
That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.
> Tailwind [is] a path to ruin.
Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.
I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance.
Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
> style bundling an issue unheard of
But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
> Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
This is what I highlighted in a previous comment. If you have a drop shadow or some padding on a component, that does not mean another component which have the same values automatically have a relation between them. So it’s mostly a syntactic shortcut at this point. And the end result has no semantics.
I've not used Tailwind yet, so please forgive me for not knowing how you achieve these things with it.
As I understand it, you add a drop-shadow to an element by writing a bunch of classnames that hook into Tailwind and apply the styles. If you want several components to use the same drop shadow, how do you _not_ repeat all those classes on all those components? If you are repeating the classnames, you're just pushing the "problem" of repeating your style rules out to the components. I'm sure there's a Tailwind way to solve this, but I don't know what it is yet.
My experience with several UI libraries and general react usage suggests you might make a new component (`<CompanyApprovedShadow/>) that applies the drop-shadow, and then each component which wants the shadow would use `<CompanyApprovedShadow/>`. But what if one's an `article`, another a `button` etc? What if one's blue and another's red? This gets complicated real fast and/or you end up with so may properties on your style components for customisation that you've lost the benefit you originally sought.
The point of repeating style directives under different classnames, in raw CSS, is that you often want to customise things. The shared values should be provided by the cascade, or variables/--custom-properties.
```
.company-button,
article,
.card {
box-shadow: whatever;
}
```
Is pretty reasonable CSS, imo. I confess I've not used this in a large project, but _every time_ I use something like styled-components, and most UI toolkits, as soon as I have to customise something I wonder why I've agreed to the abstraction.
That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.
> Tailwind [is] a path to ruin.
Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.
For me, styling on the web is solved.