I think it's the exact opposite. Having maintained some else's CSS on dozens of projects, Tailwind is soo easy to keep maintained.

You don't have to learn some else's idea of what CSS belongs to a component and how they structured it. You just go into the HTML, add or remove a couple of tokens and you can be sure yoyu didn't break anything else.

Once you've learned it - which doesn't take very long - it scales to other projects. You don't have to relearn - again - what someone else thought would make a good CSS abstraction for their UI.

I’ve done plenty of big sites with the component based approach and they are anything but maintainable.

I second that. The majority of web projects I've seen had class names scattered all over different files and it was always a nightmare to make significant changes. You don't have this exact problem with Tailwind.

Component based approach is widely addopted and proven by big and small players in the industry (I'm not even gonna name drop because it's everyone), and practically all existing frontend frameworks, it's not really debatable at this point. What is debadable is how you implement components, which probably was why yours was unmaintainable.

I believe parent is not really talking about React/Vue/Angular components, but rather about CSS components.

Framework components are indeed industry standard, and I'd argue that Tailwind (and Atomic CSS in general) also works better with them.

But CSS components (the alternative to Tailwind) are a hot mess. There are lots of methodologies, some of them are very complex, but even the straightforward ones like BEM are very error-prone when used by developers who haven't been using it for long.

same thing, aren't css components just components that are purely stylistic?

I have used the trio styled-components, typescript, react which results in highly reusable, self documented UI primitives. You write css not some made up language and you map your modifiers (in BEM lingo) to react props which is then type checked by typescript. You can also use all the existing css tooling like sass mixins etc, not that you're gonna need them.

It's not really the same thing, expecially if we're talking about the problems.

If you're directly coupling CSS components to React components, then you won't really see the issues me and GP are talking about. Names can be inconsistent because markup is centralised, it will be rarer to see overrides, people will be more reluctant to change it to fix one part of the website and then breaking all others... etc.

Big websites have been built in all kinds of technologies including PHP and Cold Fusion. That's not the question. The question is how do the utility and component based approaches compare and having worked extensively in both I'll take the utility approach every time.

If you want to change the padding in a project that's using Tailwind you only need to look for classes that begin with `p` followed by a letter for a side or x and y for an axis (same is true for margins). Those are by far the most cryptic classnames and by the time you finish reading this sentence you got it.

In a project where you have to name everything semantically you don't know where the hell the padding is going to be.

It's amazing for long term maintainability and quick prototyping. There is a lot of value in classes that does one thing well.

Been wrinting CSS for 15 years, switched to Tailwind 2 years ago, just for reference.

It is one more thing to learn but honestly it takes a very short amount of time and actually most things can be inferred