4 ms·

I didn't like it at first glance either but Tailwind is very sane. Every not-Tailwind approach I've encountered over the last 20 years has laughably and without

I didn't like it at first glance either but Tailwind is very sane. Every not-Tailwind approach I've encountered over the last 20 years has laughably and without exception fallen into the exact same problems that led to Tailwind being created: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... If you're a solo dev, sure, you're free to do anything you want and nobody will balk or complain about you causing them extra work or having to clean up a mess later. If you're on a small project and the CSS will fit onto a couple sheets of A4 paper, you also won't have enough volume of code to see major benefit because you could just rewrite an entire UI of that scope from scratch in a few hours. But on a team working with a larger codebase Tailwind solves real problems in maintaining styles across developers and over longer periods of time.

jampekka 2y ago
How does inline utility classes help with not creating a mess with a team? Merits of semantic classes and class hierarchies are very debatable. And CSS dropped the ball with style composition (which e.g. SCSS fixes). And media/container query ergonomics aren't ideal. But essentially hardcoding styles inline is a very weird reaction to these. A bit like "let's get rid of variables and hardcode values in functions because OOP inheritance caused a mess".
- et1337 2y ago
  The article linked in the grandparent directly explains how utility classes are different from inline styles: there are infinitely many possibilities with inline styles; not so with utility classes. The empirical numbers in the article are fascinating. 400+ different colors in a single CSS project that’s supposed to be “semantic”. With utility classes, you are forced to choose from a finite set of colors.
  - jampekka 2y ago
    That is not a matter of using inline utility classes. You can and probably should use e.g. CSS variables or @apply preprocessors to enforce a finite set of colors.

jampekka 2y ago

How does inline utility classes help with not creating a mess with a team? Merits of semantic classes and class hierarchies are very debatable. And CSS dropped the ball with style composition (which e.g. SCSS fixes). And media/container query ergonomics aren't ideal. But essentially hardcoding styles inline is a very weird reaction to these. A bit like "let's get rid of variables and hardcode values in functions because OOP inheritance caused a mess".

et1337 2y ago
The article linked in the grandparent directly explains how utility classes are different from inline styles: there are infinitely many possibilities with inline styles; not so with utility classes. The empirical numbers in the article are fascinating. 400+ different colors in a single CSS project that’s supposed to be “semantic”. With utility classes, you are forced to choose from a finite set of colors.
- jampekka 2y ago
  That is not a matter of using inline utility classes. You can and probably should use e.g. CSS variables or @apply preprocessors to enforce a finite set of colors.