[sorahn]

I don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup.

Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have to make a 27 div component to style an input.

The big problem is trying to convince the rest of the team that they should learn and use CSS.

[rahoulb]

I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.

I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).

One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).

[stavros]

I really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps.

Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?

[lucumo]

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.

[shimman]

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.

[sorahn]

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

[mhitza]

> 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.

[an0malous]

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.

[evilduck]

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.