They’re as cryptic as ls, cat, pwd. They have well defined semantics, sensible default, and tooling that can warn if your properties are conflicting.
In fact, with regular css you need to target elements by coming up with arbitrary class names, like .banner-main-content. Those are more cryptic imo, and completely arbitrary. (Naming things is problem #2, remember)
Do I wish there was a better way than space-separated attrs inside the human hostile xml-like format that is html? Yes. Do I want to go back to having to write custom selectors? No. 80-95% of the time utility classes is a better fit, especially with component based frameworks.
Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist.
Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codebase implemented properly.
I’ve been writing CSS for 25 years and have gone through just about everything at this point—inline/attribute styles, CSS, SCSS/SASS, LESS, stylus, Bourbon, Tailwind, Bootstrap, Ant, Semantic UI, MUI, etc. And tbh, MUI is the closest I think we’ve gotten towards rapid iteration while solving specificity issues, the problem of selector generation, proper a11y and state styling (e.g. button focus styling), and inconsistency issues, but again—only when architectured correctly.
No, React-specific? Keep in mind Tailwind is not bound to a specific component engine and works fantastic in e.g. Svelte which I'm using.
That said, it looks good I guess? But I fail to see what's so unique. Tailwind is just a lower level preprocessor that can be used with unstyled components (which is definitely not unique - there's lots of traction outside the React ecosystem as well..) From what I can see, it looks like MUI also has a utility class type of approach, or is it baseUI?
In either case, my point is that plain CSS with class selectors is not great, and that very often it makes more sense to bundle markup and styles. Well-thought-out interactions between the component- and style/theming systems is also an important part, and Tailwind clearly plays well with different component systems in the ecosystem. Other than that I don't have any interest in dying on some Tailwind-specific hill. I'm happy to see it improve or be superseded, should that be necessary.
> Tailwind [...] has its place when used correctly, but I’ve never seen a single TW codebase implemented properly.
Yes but ironically that's not necessarily a bad thing. That's the expected result of tech that is flexible enough to let you do what you need, including painting yourself into a corner. The most common mistake in framework design I've seen is "one to rule them all" - where you have to play according to restrictive rules within, or suffer greatly to break out. Tailwind is a la carte, incremental, and plays nice with other paradigms, which isn't to be underestimated.
Last commit was four years ago and it has some weird bugs, eg this page tells me "Warning: Your browser does not support WebComponents" when Mobile Safari most definitely does. https://www.muicss.com/docs/v1/webcomponents/buttons
MUI (and Joy UI) is a lot different than a utility CSS framework. It has <Box>, which is a utility CSS component, and sx, which is a theme-aware way of doing inline styles.
The difference is that it comes with a <Button> component (and of course more), which has different variants, and you can set default props and default styles at the theme level.
So where an outlined button in a utility CSS world is class="... ... ... ...", or figuring out a way to be able to express that with class="button button-outlined", in MUI and Joy it's <Button>
They’re as cryptic as ls, cat, pwd. They have well defined semantics, sensible default, and tooling that can warn if your properties are conflicting.
In fact, with regular css you need to target elements by coming up with arbitrary class names, like .banner-main-content. Those are more cryptic imo, and completely arbitrary. (Naming things is problem #2, remember)
Do I wish there was a better way than space-separated attrs inside the human hostile xml-like format that is html? Yes. Do I want to go back to having to write custom selectors? No. 80-95% of the time utility classes is a better fit, especially with component based frameworks.