It’s funny, as someone that’s been using CSS for decades I don’t really know how to respond because the scenario outlined here is not one I recognise. My button would be a <button>, so no, I wouldn’t have a .button class, it’s superfluous.

What I would have is:

- a global palette specified via CSS variables

- overrides for dark mode etc specified at the global level so I don’t have to worry about it at the component level

- CSS module files so I specifically don’t need to care for the context of my entire project, just the classes for my current component

Of course, you stopped thinking about CSS a decade ago so you don’t know about any of these improvements. Which is fine but it strikes me as a little strange to be so boastful of ignorance.

As someone who has barely touched Tailwind I’m genuinely curious: if you wanted, say, a consistent border color for use across your project how would you? Are you defining a class name in JS for use with $framework_name? And do you really style each component separately for dark mode? Repeating the same modifiers over and over?

I feel like scoped css and component libraries fixed this issue. I don’t have a .button, I just have a <Button> that has all its css self contained.

And just a shared color definition file.

You still have to remember what sizes or whatever to use for what to make it consistent, it’s just they get packed into the “class” attribute. It’s not uncommon to see very long class attribute lines with tailwind with all kinds of p-this and mx-that or whatever. I’ve also seen quite a lot of p-[whatever] tags, at which point all the consistency goes out the window.

So you end up wrapping the components (if you’re using react or something similar) so that you can centralise the styles and use a set of consistent components instead. And at that point it really doesn’t matter if you use tailwind, custom classes, per component css modules, style attributes, css-in-js, or what have you. At this point I prefer to drop the extra dependency and use per-component css files with css module imports. (Or when I do less custom styled UI’s, I prefer to use Mantine and use its attributes for layout and styling)

Yes. Bootstrap and all other CSS frameworks before Tailwind did it, too.

It's a matter of preference, but many times it's easier to have single classes so that all your buttons are consistent.

People should just use the tool they're more productive with.

Don’t you need to keep more context in your mind if you use Tailwaind to make .button_checkout_special_page_cta_widget while staying somewhat consistent?

Could you give us a few examples with and without Tailwind, including CSS variable and compose in preprocessors?

I know what you mean. But somehow that doesn't bother me. In fact it forces me to think about consistency of the design and often makes me think of a more general schema and simplifications in styling, or getting rid of something too specific/special.

What? I don't even know what you're talking about, and I've written mountains of vanilla CSS code in big projects.

Yes.

you just add `checkout` class or `big` class to your button. or use `.checkout-page .button` to modify look/size of your whatever button on the checkout page if it's style is truly unique and not used anywhere else.

Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with.

Constraints are known to enhance creativity.

Totally agree. It does break the rules, but it feels so much faster than defining class names.

On simple projects I usually @apply tailwind styles to standard elements like headings, block quote, aside, nav etc. Then just use semantic html.

Looks good and takes so little effort.

100% this. It looks terrible until you try it and it starts making so much sense.

Also works great with agent assisted development.

Your complaint is about bad developers, not about Tailwind. Using Tailwind correctly means making heavy use of components to avoid duplication. Using Tailwind also removes the burden of having to do one of the hardest things in software: naming things, which is what semantic classes requires you to do.

I think this is a protypical discussion in tech. I have seen it soo many times in different areas.

The purists ("that’s how things ought to be!") and the pragmatists ("well but it works well and people understand it seemingly").

I don't recommend css. Css is BLOATED. And tailwind makes it a little less bloated, but it's still not strongly typed, and not very re-usable, especially in code.

But your approach is from the past man, really... .btn is not reusable among pages / projects / etc. => it's always different, and when you understand that specificity wars is the main problem of css, you will not want to use your idea again.

It LOOKS cool to have a <button class="btn"> inside your html. because it's more readable. But it's NOT explicit. You fragment truth into different pieces. and it makes it IMPOSSIBLE to test things in isolation.

One last thing. Using all the "last features" of css is just putting you in a place where you depend on the browser carriers to handle things for you when I prefer personnaly to rely on myself and my craft. But that's a personal one ;)

It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way.

I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply

I disagree. I don't want to jump between two files constantly. With Tailwind I can stick to one file and never need to think about naming things.

I have the opposite experience regarding where it’s useful. In large teams , using an atomic css framework provides good guard rails and predictable behavior. I can confidently copy a marketing page or some random thing on the other side of the company and with very minimal tweaking, it will probably work. With normal CSS, the cascade is much more likely to cause subtle shifts in behavior over time as the main stylesheet is extended and modified.

To be clear, I like css and I find the cascade a great tool, but I also have first hand experienced the pain of too many chefs in the frontend styling kitchen and the havoc that seemingly innocent tweaks here or there can wreak on a site and I prefer tailwind for that reason.

Or:

  .button {
    padding: var(--gap-s) var(--gap-m);
    background-color: var(--color-indigo);
    color: var(--color-white);
    font-weight: 700;
    border-radius: var(--gap-s);
    &:hover, &:focus {
        background-color: var(--color-indigo-hover);
    }
  }

Fair comparison (i really don't like this too):

  .button { padding: var(--gap-s) var(--gap-m); background-color: var(--color-indigo); color: var(--color-white); font-weight: 700; border-radius: var(--gap-s);    &:hover, &:focus { background-color: var(--color-indigo-hover); } }

;-)

"Nothing stops you from using sky-400 and blue-400 in the same project. Consistency still depends on your discipline, not on the framework."

And how did plain css solve that? You're mixing up a few issues there.

Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.

It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI.

Is it ideal? I guess not, but there are a lot of weird gotchas and footguns in CSS too. Just because they’re in the language doesn’t make them magically more or less of a problem. For a similar weird mental shift, consider adding @starting-style and the native popover open attribute. All the good tutorials online have a warning about cascade order because as a human reading it, it can seem wrong or backwards.

Kevin Powell’s most recent video about animating display: none covers it if you want a concrete example.

they do work… for any value of work. I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another preprocessor and starts splitting files, and then a whole new set of new, made-as-you-go conventions comes in: Files per component or per view? Or rather per architecture concern? Usually a mix of them. As files are split, the class naming gets even more inconsistent.

And at that point, onboarding a new developer always means wasted time on understanding this whole organically grown set of bespoke conventions, class names, patterns, hierarchies, and so on.

Tailwind does not really have this pattern of deterioration growing along both time and complexity, it stays consistent on both axes. So it's definitely an argument IMHO.

That is kind of my point, though—you don't need tailwind-merge, really. There are two cases it solves:

One, adding classes from the outside to an encapsulated component with its own, internal classes, to make sure the outside-applied classes take priority. Either use the !important modifier on them (`ms-auto!`), put the components into a container div with the classes for layout concerns, or even better: Figure out why you need to make styling changes to a component that cannot be expressed via props. I would generally recommend components to not have outside-element styling like margins in them anyway, which most often fights with positioning later.

Two, merging prop-derived styling with base styles - for example for a `size: 'sm'|'lg'` prop. It's tempting to just use tailwind-merge here:

  const classList = tailwindMerge(
    'p-4',
    size == 'sm' && 'p-2',
    size == 'lg' && 'p-6',
  );

But that isn't necessary at all: The better alternative would be to use data attributes for visual concerns and built-in or aria attributes for interaction states. There are almost always element attributes that can represent what you want to have correctly, and data- where there are not. Then, you can just add a class accordingly:

  <span 
    class="p-4 data-[size=sm]:p-2 data-[size=lg]:p-6 data-active:font-bold"
    data-size={size}
    data-active={active}
  />

And you'll end up with easier to maintain components that derive their styles from the CSS cascade alone.

It's not true - agents will visibly struggle more with worse code bases. If anything, certain kind of maintainability matters more in this era, than before, because it is so much cheaper to just generate a huge amount of low quality code.