[mohsen1]

I used to be against Tailwind. Now that I've used long enough I can tell you that code is perfectly fine. I can read it and easily modify it. You can comment it out if you care

      <button
        class={cn(
          // layout & positioning
          "relative cursor-pointer overflow-hidden rounded-md",

          // border & background
          "border border-neutral-950 bg-neutral-900",

          // padding & text color
          "px-3 py-1.5 text-neutral-100",

          // shadows
          "shadow-md inset-shadow-2xs inset-shadow-neutral-600",

          // transition
          "transition-all",

          // background gradient positioning
          "before:absolute before:inset-0",

          // background gradient
          "bg-linear-to-b from-white/20 to-transparent",

          // hover 
          "hover:bg-neutral-800"

          // active
          "active:bg-neutral-950 active:shadow-none active:inset-shadow-neutral-800"

          // disabled
          "disabled:opacity-50 disabled:cursor-not-allowed"
        )}
      >
        After
      </button>

[cogman10]

Reading though this, I really have to wonder how this is better than

    <button style="css blob">After</button>

Why make a bunch of css classes when it looks to me like the "style" will be roughly the same amount of code and readability.

[douglee650]

I am a convert, once you get the hang of the configurability it's very good (Tailwind 4). You don't have to go to separate files which is more streamlined, esp when doing in React.

I like to format in logical chunks per line, for example here's a pretty complex grid setup that is easy to adjust in the template:

    ----
    <section className="
      w-full
      px-8 py-16
      md:px-16
    ">
      <div className="
        grid
        gap-2
        auto-rows-[minmax(0px,1fr)]
        grid-cols-[repeat(1,minmax(4rem,1fr))]
        grid-rows-[repeat(1,minmax(4rem,1fr))]
        md:grid-cols-[repeat(6,minmax(6rem,1fr))]
        md:grid-rows-[repeat(3,minmax(6rem,1fr))]
        xl:grid-cols-[repeat(8,minmax(6rem,1fr))]
        xl:grid-rows-[repeat(2,minmax(2rem,1fr))]
        justify-center
        ">
    ----

[wwweston]

You’re correct in the sense that they’re both big noisy blobs that dilute semantic/functional signals.

You’re neglecting the design system work that goes into tailwind classes. I don’t particularly like its choices (and generally consider tailwind to be a minimal local maximum for a set of tradeoffs deserving of faint praise), but they’re something, and in an engineering culture that won’t adopt a better mindset or better tooling, it’s something that solves a few problems well enough.

[dontlikeyoueith]

> generally consider tailwind to be a minimal local maximum

I feel like I've been nerd sniped trying to figure out what you mean by this.

[shkkmo]

It took a sec but I parsed "a minimal local maximum" as "from the set of all local maximums, this local maximum is near the bottom." Thus it is a local maximum, so any small change produces a worse result, but it is one of the worst local maximums you could have found.

[dontlikeyoueith]

> Thus it is a local maximum, so any small change produces a worse result

I have ML engineer brain, so to me any small change from a local maximum is an IMPROVEMENT (because we try to minimize loss functions).

Your reading makes more sense.

[nine_k]

It's the lowest hill in the range of CSS frameworks, it's not reaching the heights of proper semantic CSS, but the valleys of haphazard, unsystematic style attributes are an even lower point.

[vehemenz]

What do you mean by "proper" and "semantic?" The CSS spec never took much of an opinion on how classes should be organized or mapped to elements in the DOM. It's a technical standard. The way people used to write high-abstraction CSS was completely a cultural convention that, in hindsight, overstayed its welcome.

[wwweston]

Heh, fair, not a super clear phrase. What I’m trying to evoke is that tailwind has a few merits that do produce a local elevation on a few points of front end dev experience… but not much (and for some the tradeoffs cancel it out) and that more is possible.

[tshaddox]

The simple answer is that inline styles lack support for a bunch of basic stuff like pseudo-classes and media queries. I think the Tailwind team would tell you that they would love to have native web support for full-featured inline styles and that this would obviate many of the reasons to use Tailwind.

[danenania]

The real equivalent to that example would be something like:

  <RetroButton variant="primary" />

[dsego]

The style prop doesn't give you a design system, it's just raw values. Maybe you could use something like open props though.

https://open-props.style/

[chuckadams]

You can override classes, not so much inline css.

[cogman10]

Is anyone ever going to override the "px-3" class?

You can also change styles through javascript if you really want to.

It just seems like we've lost the entire reason for css in the first place when every css attribute gets turned into it's own class.

[chuckadams]

Special cases in layout are a thing, happens a lot once you start nesting third-party widgets. So yes, there may be enough of a use-case for overriding px-3 that it wouldn't make sense to specifically omit it as a utility class -- to say nothing of it being useful as a utility class to begin with.

I only sprinkle in the very occasional tailwind class via UnoCSS. I don't have the fire in me to dig trenches for either side of this battle that some people want to make all this into.

[mvdtnz]

> Is anyone ever going to override the "px-3" class?

No, but they will change things like their constants ("bg-neutral" or, in this case, the spacing constant).

[hnthrow90348765]

This is some "put the comma in front of the column name in SQL" logic