Or: How I Learned to Stop Worrying and Love Utility-First CSS Frameworks

If you go back in the history of web development far enough, everything was an inline style. Then CSS came along and brought a decoupled and powerful way of styling your site, and a lot of headaches for web developers who weren't clear on how to float with the tide, to overflow a metaphor.

That would be a lot to repeat in several of your BEM-style components, so it's handy to have some global CSS classes that take care of it. A utility-first CSS framework tries to provide that DRY (don't repeat yourself) convenience to all your CSS styles. In the case of Tailwind, nearly every CSS property you can think of writing has a pre-defined class ready to go. If you want to see it for yourself, go ahead and scroll through Tailwind's docs, I'll wait.

Okay, that's a bit more concise, but what of it? Where's the advantage from writing CSS in a slightly more terse format? For one thing, reusable utility classes help us keep consistency. The color of that tan background, or the pixel radius we round off the borders is the same everywhere we use it, which is something we'd previously use Sass or CSS variables to ensure. But more on that later.

But wait, we just did a couple things here that break some of the fundamental rules of CSS! First, by using classes that describe what the page looks like instead of the function of the element, we're tying styling back to our content! Well... sort of. Web development's changed a lot since that rule came about. We're not often making entire documents that contain our entire HTML structure and repeating it across several documents. In this case, our card is going to look the same wherever we use it, regardless of if it's getting its styles from the .Card class or directly in the HTML.

You could further customize this to give you automatically generated light and dark shades of your base colors, using a PostCSS plugin such as PostCSS color-mod(), similar to Sass' lighten() and darken() functions.