But since this has name of Google attached to it, many people will mindless ape it to the detriment of experience of their users.
But since this has name of Google attached to it, many people will mindless ape it to the detriment of experience of their users.
This wouldn't be so much of a problem if so many corporations also hadn't somehow decided that MUI was the next Bootstrap and have been treating it as an underlayer in their Design Systems, most of which aren't actually supposed to look like Material and don't really benefit from being huge additional libraries of CSS and components on top of MUI. I blame Figma for this. I don't know that it is any one specific thing Figma is intentionally doing, but the more design teams use Figma the more they seem to think they "need" a safety blanket of Material UI somewhere in the design stack that they won't actually use correctly or well.
As an engineer often tasked with performance work, I hate how much of Material UI's braindead approach to performance reflects on me in ways I can't do anything about "because that is the design system you wanted" (not the design system you needed). I wish Material UI would either get significantly better or just die already.
But I'm a fan of the cascade done right and with CSS Grid and CSS Variables and @layer vanilla CSS cascade is at an all time jam right now. I'd be surprised we aren't seeing more "Design Systems" in that space, but I've got a feeling given how much you can cut from a Bootstrap or Bulma today for CSS Grid/CSS Variables that maybe we aren't seeing a lot happening there simply because not a lot needs to happen there. People happy with the cascade are getting closer and closer to also being happier with "no frameworks" again. Vanilla CSS feels good to work in again.
There's two ways of answering this, but both amount to a yes
1) I certainly think much more highly of the recent plethora of tailwind based component libraries than the previous generation, which mostly don't require me to actually use tailwind directly (mantine, daisy). Component library developers seem to like it _a lot_, and the outcome is great. If they're happy to use tailwind and I'm happy with the library that is built on top of tailwind, then I'm happy with tailwind.
2) The other way of answering this is if I'm using tailwind directly. To this point, yes, I'm still happy. The metaphor I've used is that tailwind is to css is as ASM is to machine code. It's still low level, but far, far more ergonomic. And in the end, you often end up using a higher level of abstraction anyway (again, see Daisy, mantine).
>Vanilla CSS feels good to work in again.
FWIW, I really do agree with this. But I think tailwind + postcss is even better still.
- Mantine doesn't use Tailwind. It's overly React specific for many of its components that don't really need to be React components but could be Vanilla or Web Components, but it doesn't seem to be anything like the Tailwind approach.
- Daisy seems really funny to me because it seems the long way around to be a Vanilla CSS framework while still being too much Tailwind.
- (ShadCN is definitely the worst of both above things, utterly React-specific and taking the long way around from Tailwind back to things that resemble Vanilla CSS, only with extra React for React's sake)
It's basically like looking at a Figma export and complaining about the performance of it; any actual implementation would be done for any user-facing products realistically will be entirely unrelated both technologically and organizationally.