I always throw away colors on every project and change it to semantic naming. I add / remove fontsizes, spacing whatever project needs.

I've been also confused how can people use it without touching the config but apparently many do. I guess when developers don't have particular design or brand they just pick from whats available.

You mean like CSS? Why recreate raw CSS as classes and use that in your CSS? I'm sorry but all I'm seeing is a huge disconnect.

You either take the default configuration with a few tweaks, for example if you are a programmer first.

Or you define a more complete, unique system upfront, for example if you implement a bespoke interface from a UI designer.

If you see emerging patterns that ask for composition, then you can easily compose utilities and give your components semantic class names.

It is a blessing for productivity, performance and maintainability, because it decouples CSS concretions by introducing a light, composable abstraction layer between raw CSS and component/semantic CSS.

Think of it as a lightweight, well defined query builder on top of SQL that you use for safe parameter binding and composability. (The analogy leaks a bit but you get the drift)

https://tailwindcss.com/docs/theme

Its slightly more work, but well worth it.

Regarding the 'class soup' thing, I found that using 'primary-nav', etc to also devolve into soups, albeit, soups of a different taste.

It most likely does, but it's not old and popular enough for people to have accumulated enough technical debt within systems built with it.

It just comes with a config out of the box that is highly usable for any app and any need without customizing. Purge then allows you to strip out all the extra unused CSS in production.

(I think I understand that the approach is that I'd then change what those definitions mean centrally - but that won't help me if I decide that two properties which are currently different should be the same, or vice versa).

In a complicated codebase with multiple devs, the number of times you could confidently make a "one-place-CSS-change" to a semantic layout class is very small. It's likely that in one place or another, some dev made an assumption about your `sub-container` class or whatever, which causes your change to break their layout.

Most large codebases thus end up with a TON of very specific class names (often used in one place), so the dev can be confident in their layout; this is the biggest contributor to unmaintainability that I've seen in large applications.

If everyone is forced to use e.g. d-flex justify-content-center ..... it hugely improves readability as any developer can quickly look at any layout and see what is going on without building a mental index of semantic class names that the original dev chose.

Of course if you have a very simple page with just some cards, a couple page layouts, that is one thing. Probably can get by with just a myCard class that works everywhere on the site.

But in most projects, as the number of custom components grows, nobody wants to go back and touch (break?) old CSS, so they end up just writing a bunch of fresh stuff for this new feature and throwing it on the pile.

This problem happens often, while the refactor-in-one-place case happens very little.

I could see a use for this in JSX though.

EDIT: Instead of custom CSS classes, Tailwind recommends extracting components like the other commenter pointed out. https://tailwindcss.com/docs/extracting-components

The parent comment was specifically about not using components.

But you use your Bootstrap/Tailwind utility classes in JSX. Now your styling is tightly-coupled to your component again. Isn't that just CSS-in-JS with more steps and less power?

In my opinion tailwind works out best if you use components or use template partials in a component style. In that case, there won‘t be that many places where you declare what your primary nav looks like. You just go into the PrimaryNav component and change the class.

In the other case you mention, you may want to use a semantic color name, which you can do in tailwind.config.js no problem, so your color class could be bg-action-300 or bg-red-action. Now this is not the same as some action-primary css class which could contain color, layout, an IE hack whatever. It‘s only predictable design system primitives like color, spacing, typography style, shadows etc. You can think of these like types in a programming language because they are enforced and predictable, not ad hoc thought up by developers per project.

Both of these things have emerged more strongly in frontend in recent years, so it makes sense that different things make sense than 10 years ago (semantic classes)

> So if I want to change the colour of all prominent-actions across my web app

As I was just saying, it's naive to think this would ever be a simple one-line change of a constant. It will inevitably be a moderate sized undertaking no matter what you do, because of all the cruft and coupling that may have built up under the old assumptions. But it's also not something you're doing every day, so it should be far from the first thing on your mind when thinking about which patterns are most helpful to use.

But, even putting all that aside, using utility classes like Tailwind doesn't even prevent you from abstracting as much as you'd like. You just do it at a different level. You're not likely writing static html on every page anyway, you're probably using code to generate your html whether that's React components, server-side rendered views with partials and templates, templates in a static site generator, etc. So you can still do the abstraction you want at the level of your components or your view code instead of via css classes. In that world you can think of tailwind as just a higher-level version of the underlying css properties. And you're still free to repeat yourself or DRY-ify your code as much as you want (though as I allude to above, I tend to think DRY in programming is often very overrated).

You avoid repeated classes by extracting components (either template partials, or actual components if you’re using a front-end framework). The components themselves define how they look, and then you assemble them, perhaps with a few additional classes for things like spacing. If you need to change a component you don’t need to go and change classes everywhere you’ve used it, you just change the component itself.

If you feel like reading further, Tailwind’s author explained his rationale very clearly in a blog post a few years ago [1]

[1]: https://adamwathan.me/css-utility-classes-and-separation-of-...