[ramesh31]

>I genuinely don't see how you think it's more difficult to debug class="bg-blue flex items-center" versus class="SpecialBuggyComponent" and then having to cross-reference and dig through a bunch of styles in a css file.

Because it's never just 'class="bg-blue flex items-center"'. It always becomes 'class="bg-blue flex items-center text-base font-sans font-medium rounded-lg bg-gray-100 text-black py-3 text-center cursor-pointer"'

And now I'm spending 20 minutes digging through every single one of those classes to find the reason my 2 lines of added CSS for this ticket won't apply without an !important.

[kaishiro]

What is it that you find confusing about each of those class names though? They're certainly more descriptive than "SpecialBuggyComponent", and it should be easy enough to infer what each of them does even if you're unfamiliar with tailwind.

[dalmo3]

The verbosity was a turn off for me as well until I found eslint-plugin-tailwindcss which enforces predictable class ordering, making those long strings much easier to understand at a glimpse.

[andrei_says_]

So the utility class lists become so long, tangled and unmanageable that we write software to order them in a predictable way and make them somewhat comprehensible and more manageable.

Does this not raise a red flag?

I know I’m probably a dinosaur using SCSS, BEM and ITCSS but I find my code based logical, tidy and a pleasure to work with.

I do have the tailwind color and spacer presets as variable maps accessible via short functions so I can say color: c(yellow-500); in my SCSS and have all the benefits of standardized colors, spacing, font sizes.

[wildrhythms]

Either way, you've had to dig through styles; the difference is that Tailwind keeps the styles at the component level, without the arbitrary naming and additional file requirements that traditional CSS classes introduce.