It's based on how often you use a helper. For instance, changing letter spacing is verbose (https://tailwindcss.com/docs/letter-spacing) as it's not something you use that often. Tweaking spacing is very common and "padding-horizontal-2" uses an awful amount of characters.

In what context is this "an awful amount of characters" an issue? GZip compression is fairly standard these days, and languages based on plain english (or similar languages) has a better level of compression than random text because of repetitive nature of sequences of characters.

I can't believe that mnemonic based languages are easier and more readable than something closer to a natural language. And with the assumption that code is written for humans first, computers second, what is the point of inventing a language that's less readable than the one it's trying to replace? CSS compresses particularly well, as every Atomic CSS based framework tends to point out on it's landing page!

It's an awful amount of characters once you multiply it. For instance, the first example (https://tailwindcss.com/docs/what-is-tailwind/) would be twice as big:

    <img class="block h-16 sm:h-24 rounded-full mx-auto mb-4 sm:mb-0 sm:mr-4 sm:ml-0"

    <img class="block height-16 small:height-24 rounded-full margin-horizontal-auto margin-bottom-4 small:margin-bottom-0 small:margin-right-4 small:margin-left-0"

After spending more than, say, two hours with Tailwind you'll probably read the first line much faster than second one (since there's less to read and you don't need to scroll). Humans are very good at pattern recognition, and you'll quickly read "mb" as a symbol in itself and not as "m[argin] b[ottom]".

> I can't believe that mnemonic based languages are easier and more readable than something closer to a natural language.

Well, it's worked out pretty well in mathematics. This is not about file size at all. It's about defining an "alphabet" of common concepts.

Ah, I see your issue: you do know you can have whitespace inside attributes? You don't have to clump all the class names on one line. Scanning vertically is quicker than through the horizontal line-noise of both your examples.

    <img class="
        block
        height-16
        small:height-24
        rounded-full
        margin-horizontal-auto
        margin-bottom-4
        small:margin-bottom-0
        small:margin-right-4
        small:margin-left-0
    ">

This also has the benefit too, that if you use version control line-based diffs to see what's changed, it will highlight the specific css class name that changed. Handy if you need to ensure that whenever you change the bottom margin, you can see at a glance whether the small prefixed one has been updated too.

On the other hand if you regularly need that many classes to style an element, perhaps it's a good place to refactor commonly occurring class names into a set, and label that set with a meaningful identifier.

As for mathematical notation, it's about as understandable to me as my understanding of Hanzi.

It's a decision to optimize write-ability, not readability. Not sure why this is so puzzling.

It's puzzling because the same people then shit on Perl for being "write-only".

I agree with your sentiment. I think this is because half the programmers like mnemonics and the other half prefers English, so no matter what you do people criticize your choice. People call Java verbose and perl write-only.

At that point, why not just write actual CSS?

Because you'll have 29 different margins, 67 different left paddings, etc all over the place. Tailwind allows you to create a consistent design system. CSS was supposed to be "write one class, use it everywhere instead of inlining". Usually it ends up with nobody reusing that class and everyone creating their on in the same codebase. There's an article I don't have a link handy, which explained how ridiculously many classes were used by GitHub/Lab, Airbnb, etc. Now even GitHub have their own utility based CSS system and others are following along, including Bootstrap with their CSS utility classes.

> Because you'll have 29 different margins, 67 different left paddings, etc all over the place.

That's not really the case since SCSS became a thing. If SCSS doesn't help you, Tailwind won't, you can ignore their classes just as you could ignore preset constants.

Honestly, to me it seems like people are just starting "fresh" with a benefit of some experience, and ascribing the benefits of experience to the tool.

I've used SASS for years, and yet switching to tailwind felt reaaally nice. have you tried it for yourself, or are you just assuming that you understand the practical differences?

Tailwind isn't a particularly new invention. I've worked with similar tools developed in-house years ago, and have no desire to do it again, no.

you have that with tailwind too, lol. probably even worse the bigger your app is.

Can you elaborate? I can't agree with you. Tailwind is meant to provide a consistent design system, of which CSS size should never get out of hand (which is the case then using regular CSS). Whenever I use Tailwind, I end up adding maybe 20-30 lines of CSS and I never have to open a CSS (or other sass/less/whatever) ever again. Have you tried Tailwind or you're just assuming what you're saying?