This shaping page format is different from the others; it's meant to document the gaps in today's ecosystem. It aims to answer: Why is MUI investing time into Pigment CSS when it could rely on an existing style library and focus on Design Engineering with the components? Why is there a purpose in doing such?
Styles are edited within the markup instead of being separated.
Heard in:
No need to find a good name for the CSS selectors.
Heard in:
The plug-in that auto-sorts the properties makes it so much nicer during code review.
Heard in:
A theme with strong default design tokens.
Heard in:
Writing style is easy. No hard-to-reach key.
Heard in:
Very fast to add styles and generally work with CSS once you get up-to-speed with the classes that don’t map 1:1 with plain CSS declarations (e.g., leading-lose, which is the same for line-height: 2).
Just CSS. It makes adoption easier and future-proof.
Heard in:
Performance.
TODO: Need to benchmark. It's strange that Vercel pushes so much for Tailwind CSS and are not really using it on their own marketing, docs, etc websites (they have a Tailwind CSS asset but when you clock it in the network panel, the website seems to work normally). There are concerning aspects of Tailwind CSS. I get the impression that because of tailwind-merge (6kB) bundle + its runtime + its Atomic CSS that Pigment CSS’s css()/ sx API is faster by a non-negligible margin.
It doesn’t scale:
Heard in:
There is a plateau of adoption and depth in the market?
Typesafe. It’s not that bad. There are eslint plugins, Prettier sorting extensions, and VS Code extensions that both bring autocomplete and mistake detection. Heard in:
So https://x.com/jamesqquick/status/1796557600273977587 might happen (absolute is not spelled correctly), but only if you don’t have the right tools in place.