The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?

This is a totally real problem and one of the things that put me off of using some of the existing utility frameworks before creating Tailwind.

With Tailwind, we don't try to pretend that you will never need to write any CSS, and instead embrace that fact and give you as much tooling and guidance as possible on how to extend the framework the way it was intended to be extended.

In the situation you're talking about, you would extract a "component class" using Tailwind's `@apply` directive to enforce that the component followed your design system:

https://tailwindcss.com/docs/extracting-components

Then you could update all your buttons at once by making changes to that component class.

The key with Tailwind is that it encourages a "utility-FIRST" workflow, not a "utility-ONLY" workflow. Build your UI with small primitive utility classes, and extract components only when you start to experience painful duplication problems.

You can use a component. I personally design first using only tailwind utility classes. Once I reach a near-ready state I factor out the repeated code into custom components that will be easy to change in the future. That way I also don't have to wait for css to compile while I'm still making a lot of changes (I know, like 150ms right?).

.btn {

  @apply .bg-grey .rounded-sm;

}

Generally you’d have your button html and classes inside a component so you’re just tweaking that one component.

Then it feels like we're just back to writing normal CSS classes.

The real value for me is just being able to sit down and start. The odious first impressions of tailwind are true. But try it out. I like it because I don't waste time flipping back and forth between my document and a style sheet. I don't waste time thinking of clever class names. I don't wait a second to compile css and refresh for every small change I make (even though developer tools have been helpful in this regard, you can only make so many changes at a time). I still break it down into components later but the actual design process is more fluid.

I use it in production at work. Wasn't my choice. I should have pushed harder for Bulma. Not only is the HTML just a hair length's away from `style` tags, but if I'm writing the same set of classes on more than 3 elements I compose a component.

Then I also have to write our own classes for modals, cards, toasts, lists, media objects, drop down menus, side menus, breadcrumbs, buttons, forms, their labels, images and their captions, and get the right mix of responsive utility classes as well so they all play nice together.

I'd rather just pick a framework that lets me customize the corner radii, padding, margins, and be done with it.

Buttons are sort of a pathological example. Most components in a web app are container-like things, with collections of a couple of buttons and other things that need to have a cohesive look, internal and external positioning, etc. And how often do you end up with one large, crufty CSS class for each of those, or a handful that are closely tied to each other and the markup anyway? Frameworks like this allow you to easily move that gunk from the CSS to the HTML.

The secret is that a solution where typical CSS classes are the exception and not the common case, is generally more useful.