Yeah, good question. At a high level I think the best analogy is React: when I first saw it, I wasn't entirely sure about mixing in HTML with my Javascript. It seemed strange. Now that I've been using React for years, however, collocating these things seems like the obviously correct thing to do.

Tailwind is similar: instead of extracting styles out to a separated styled component or even a separate .scss file, you collocate them with the rest of your layout. When I read code using Tailwind it's easy for me to "see" how things will look in a similar way that I can "see" how a React component will function at run time.

More concretely, I think these three things were important for me:

1. There's a really solid design system underpinning the Tailwind utility classes. With styled-components you start from nothing, and with off-the-shelf component libraries (e.g. MUI) you get a design system that isn't quite as well thought out. Tailwind's classes just work together really well out of the box because the defaults are so sensible. I'm not a designer, so this is a really big win for me.

2. Components help prevent class soup. I suspect I wouldn't enjoy Tailwind quite so much if I were writing plain HTML, but for things which _do_ need to be reusable like button styles I'm still writing code that looks like `<Button>...</Button>`. Nothing really changes here from styled-components -> Tailwind other than how the styles are written; they're equally maintainable.

3. One-off snowflake UIs are really easy to implement, because you can just write your classes right then and there. I've never worked on a nontrivial web application where _everything_ fits cleanly into the design system, and going through the ceremony of creating a styled component just to add a little bit of additional spacing is a pain. It also sucks for maintainability because a name like "Spacer" doesn't tell me anything about the styles, so I need to context switch and jump to the definition. In contrast, seeing "mx-2" instantly tells me what's happening.

I do think Tailwind's something that benefits from first-hand experience, though.

I think a lot of people overlook #1, and it is important. Writing Tailwind feels fast, intuitive, and looks good by default.

It’s pretty universally described as extremely ugly to the point where the most common request for years is people asking how to build component classes in CSS in order to move it out of the HTML.

I'm talking about the design aesthetic that is baked in. The actual results, not the code.

But you could have the exact same design system in native CSS. I don't get why this should be considered a Tailwind benefit given that it comes with a lot more baggage. Am I missing something?

edit: syntax

Sure, but why build it myself when tailwindcss exists. Every unused class gets purged so it doesnt make a difference in size.

Not op but here is my take:

- styling is scoped to your components. You won't break your UI trying to refactor rules & selectors

- by default you don't need to invent class names. The components provide enough context

- it forces you to make a selection of colors an spacing, leading to a more coherent style.

- it is easier to understand than a lot of other css frameworks. It is just a "basic" rule generator with some QoL like automatically pruning the rules you are not using in the production code.

I'm currenlty working on a project which has used styled-componentes extensively. I plan to entirely remove it (and I am considering tailwind or vaniall CSS to replace it) for the following reasons:

1. It increases mental overhead. It is not possible to tell whether a component contains pure CSS styles or adds some functionality, unless you open it and read its code (in that point, it has lost all of its benefit for me). With CSS classes or even HTML style attribute, this distinction is immediately obvious: style vs. function.

2. It clutters the codebase. You'd find all sort of little components sprinkled everywhere.

Both of the above critics could be addressed by implementing a convention, however. For example limiting the use of styled-components to a specific package. The second issue is mostly programmers' fault, not styled-components. However, with CSS I don't have any of these problems to begin with.