You'd end up with much larger source.

Imagine you have a React component you render once for each element of a JSON array:

    products.map((product) => (
      <li style={{color: "rgb(180 83 9)"}}>{product.name}</li>
    ))

which would be the equivalent in tailwind of doing

    products.map((product) => (
      <li className="text-amber-700">{product.name}</li>
    ))

In this case, the `class="text-amber-700` attribute isn't going to be much different in size than `style="color: rgb(180 83 9)"`, but tailwind has other utility classes such as ".grid-cols-3" which would be equivalent to an inline style of "grid-template-columns: repeat(3, minmax(0, 1fr));"

It also lets you set up a minification pipeline which turn the "text-amber-700" example above into something like

    .xJ2Xa9 {
      color: rgb(180 83 9);
    }
    ...
    <li class="xJ2Xa9">Awesome product #1</li>
    ...

I'm sure you could minify inline CSS similarly, but I suspect the tooling there isn't as polished.

How is that different from writing

    li.product {
      color: amber;
    }
    ...
    <li class="product">Awesome product #1</li>
    ...

You wouldn't if you used solutions that compile to CSS modules or another runtime-free solution. (astroturf, linaria)

Write me a media query, or a hover state in inline styles.

You can't. So you fall back to classes and CSS and now your styles are split in the HTML AND css. Tailwind, in a very basic form is exactly this solved.

I love inline CSS!

Because it would be absolutely terrible.

What would be the difference?

Performance, brevity.

TW classes are a lot more concise and provide a "design system" vs raw values and browsers are good at applying classes vs parsing inline styles for every element.

I am really curious about the performance claim.

It seems to be mostly a matter of where the performance penalty is paid.

Browsers either parse CSS (mostly) "ahead" of HTML (tailwind CSS classes), or as they parse HTML (inline CSS): they still got to parse a very similar amount of CSS, except if you've got the same "rule" applied in a number of places (though in that case, element-based CSS rules probably win-out).

Do you perhaps know of any benchmarks where the actual real-world effect is visible?

first google result https://www.sderosiaux.com/articles/2015/08/17/react-inline-...

> parse HTML (inline CSS): they still got to parse a very similar amount of CSS,

I have no idea how it works but I imagine there is a difference to

    parse class.css
    parse el1.html
     apply class to el1
    parse el2.html
     apply class to el2

vs

    parse el1.html
     parse el1.css
     apply style to el1
    parse el2.html
     parse el2.css
     apply style to el2

Honestly the argument pro/con performance is irrelevant to me, writing this 100 times

  class="text-lg"

is immeasurably more ergonomic than writing this 100 times

   style="font-size: 1.125rem; line-height: 1.75rem;"

Or even worse

   class="shadow"

and

   style="box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)"

and that's only one style.

That benchmark tests something slightly different with a focus on repeated CSS rules (and all from JS even): it's not surprising that's faster, though it's interesting it's faster even from JS (I acknowledged expecting that, and that CSS rules per HTML element are likely even faster, eg. a td rule with all the styles on it would probably win over that too).

I do get the terseness point, but unless you are completely happy with Tailwind definitions, it makes code less maintainable rather than more IMHO: instead of having a familiar place to look up the "shadow" definition (if that's not really doing what you want) in your own CSS or HTML file, you need to look at tailwind CSS inside your dependencies, or inside a debugging console in your browser.

I am also unhappy about any code where you'd have to write even `class="text-lg"` a 100 times: perhaps I am still living in the foolish dream of semantic markup, and I would hope you can structure your document in a way where styling is context-dependent: so perhaps you put class="text-lg" on an "top-level" element, and then only adjust nested element text sizes where needed.