Plain CSS is very useful if all you have is an HTML page. Giving all buttons a consistent look is nice and easy if you can just specify that with a nice CSS selector. That's also the only place you can do it without changing all <button> tags.

If you're building a component-based UI, that need is less, because all your buttons are created in a specific Button component. That's also an easy place to attach styling. You don't even need a separate file anymore.

But that's a wash. It gets much more interesting if you have components that are used in different contexts. Unordered lists for example can be an unordered list in the running text, but also a navigation list in the footer, the menu, or as tabs. There's some semantic logic to having those things as lists, but they usually look completely different.

You'd use classes and descendent selectors to deal with those differences. The downside is that those leak very easily to instances that you don't want them in. Having normal lists inside tabs inside running text requires careful engineering of the selectors.

The larger and older your project grows, the harder it becomes to get that exactly right in a future-proof way. At some point changing something for one item somewhere, can completely mess up something on another part of your site.

Inline styling, or Tailwind-style utility classes, are useful in that situation. Every component gets to be responsible for the way it looks and no longer has to care what anything else does. HTML tags that are used in different contexts will have their context right there, next to the styling. All part of the component.

The few remaining things that you need for consistency between components (colors, sizes, fonts, etc.) can be handled with CSS variables.

Why not scope your styles in the component, using either a css in js approach, like Vue, Svelte, and surface do, or use the modern css @scope property?

That's interesting context, thank you.

You aren't using it wrong, the only thing tailwind does better than 99% of devs is having default values that both look nice and mesh together well.

Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.

> having default values that both look nice and mesh together well.

So 99% of the value can be achieved with strict linting and autocomplete plugins.

Yes? I don't think anyone has ever argued that tailwindcss has a moat on anything, it has always been championed as a library created by a designer + dev who care about good UI design.

At least that's how I always seen it billed as, even when Adam was live streaming and saying as much in like 2018/2016.

If you're experienced with or like the way CSS works, and you didn't like Tailwind, then you were probably using it correctly.

> and it seemed like setting style="" on all elements, but with extra steps.

And extra benefits.

Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.

CSS is a little too low level for most web app design, Tailwind is a bit higher level and more concise than its CSS equivalent. It also has a bunch of sensible defaults for colors, sizes, spacing, and type.

Encapsulation, e.g. utility classes (and Tailwind, by extension) solve for project management or organization level problems, not styling problems directly. The nice defaults are a bonus but the actual value is a common and agreed upon approach to avoiding a write-only stylesheet that grows forever and for not fucking up cascading styles that impact someone else's feature or page you didn't intend to and causing releases to grind to a halt while they sort out what you did. Everyone here who misses that point is basically broadcasting how they are the cause of long term problems in their project or at their organization.