[nailer]

That’s definitely true. I just wish tailwind encouraged consistent styling (by having a design guide and variables) rather than styling individual elements in their documentation, which means someone has to clean up the mess later.

[cageface]

In practice I find UI built with Tailwind to be a lot more consistent because all the dimensions are built from standard values instead of custom dimensions for every css class. The bigger problem in my experience is that most designers are too lazy to set up a type and color scheme up front and just drag whatever looks good to them in their sketch/figma files.

[nailer]

You mention the issue being solved is having standard dimensions.

We’ve been doing this in CSS for quite some time using variables. This didn’t require adding a fairly leaky and thin abstraction on top of CSS and adding thousands of copy pasted singleton styles to our projects.

[cageface]

I have a few hundred tailwind classes left in my projects after a purge css pass. If you have thousands you probably should start looking into extracting some components. If you literally have "a few thousand" colors in your UI you need to find a new designer.

And CSS variables are great but way more verbose and still require you to come up with "semantic" names for everything.

[nailer]

> If you have thousands you probably should start looking into extracting some components.

This is confusing component reuse with design system reuse.

Two components may have completely different purposes, but they both have a certain rounding, palette, and other styles.

[cageface]

@apply is your friend here.

[nailer]

100% agreed that sharing styles with @apply is exactly how to solve this.

However Tailwind tells users they shouldn't be doing this, encouraging them to paste the same mixins on every element they want them.