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:
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.