Yes as we have seen through the years, pure CSS has resulted only in energy-efficient websites that are highly usable.

Slash

Ess

If you don't know how the lower level layers under your current abstraction work, you end up on accidentally quadratic.

Am I more clear now?

Do you know how Tailwind works? What you say is generally true, but I don't really see how it applies to TW...

No of course I don't. And due to javascript's reputation, I assumed. Because what I said IS generally true for the js bubble.

The sad part is i don't even feel guilty for assuming, because this area of programming has a well deserved reputation.

Even if this thing doesn't use javascript, can you guarantee the generated CSS doesn't put the browser's layout engine in an infinite loop or something? Especially without knowing CSS, like the OP suggested it's normal?

>Am I more clear now?

Nope

> can you guarantee the generated CSS doesn't put the browser's layout engine in an infinite loop or something?

the way TW aproximatively works is to collect a set of used class names from your code (e.g. flex, min-h-screen, bg-[url(/img/grid.svg)], absolute, etc.) and produce the CSS for those classes.

For the random 5 classes above it would produce:

    .absolute{
      position: absolute
    }

    .flex{
      display: flex
    }

    .min-h-screen{
      min-height: 100vh
    }

    .bg-\[url\(\/img\/grid\.svg\)\]{
      background-image: url(/img/grid.svg)
    }

By default TW also includes a CSS reset preamble and defines internal variables.

Sometimes the generated css contains complex selectors but as far as I know it is not a common occurrence

    .space-y-4 > :not([hidden]) ~ :not([hidden]){
      --tw-space-y-reverse: 0;
      margin-top: calc(1rem * calc(1 - var(--tw-space-y-reverse)));
      margin-bottom: calc(1rem * var(--tw-space-y-reverse))
    }

In other cases more css variables (custom properties defined in the preamble) are used

    .-translate-y-1\/2{
      --tw-translate-y: -50%;
      transform: translate(var(--tw-translate-x), var(--tw-translate-y)) rotate(var(--tw-rotate)) skewX(var(--tw-skew-x)) skewY(var(--tw-skew-y)) scaleX(var(--tw-scale-x)) scaleY(var(--tw-scale-y))
    }
    .shadow-xl{
      --tw-shadow: 0 20px 25px -5px rgb(0 0 0 / 0.1), 0 8px 10px -6px rgb(0 0 0 / 0.1);
      --tw-shadow-colored: 0 20px 25px -5px var(--tw-shadow-color), 0 8px 10px -6px var(--tw-shadow-color);
      box-shadow: var(--tw-ring-offset-shadow, 0 0 #0000), var(--tw-ring-shadow, 0 0 #0000), var(--tw-shadow)
    }

I believe that CSS performance is mostly dominated by size in bytes of the stylesheet, number of properties, complexity of selectors, and frequency of updates. I suspect that TW improves most of these metrics in exchange of bigger html class attributes.

https://play.tailwindcss.com/

Tailwind is not a performance hit, anyone who knows how it works knows that. Maybe stop throwing random accusations you can’t back up… it’s such low quality commenting.

Edit for the downvoters who don’t know how it works: there’s zero js being run at runtime, it’s a pure css framework that generates as-minimal-as-possible css files. And it’s not class lookups that cause whatever issues parent comment is talking about.

Tailwind is not Styled Components, there is no dynamic component to it.

In that regard it is pretty similar to Sass.

The main effect on performance likely are bigger html documents (which can be optimized) and simpler CSS selectors.

In real world usage I would honestly guess that using simpler css selector (with far fewer propagating updates) is a net performance win.

(It was one of the showstopper for the :has pseudoclass, for a long time nobody knew of a way to implement it efficiently)