What is the way forward for styling @ mui?

[aarjithn]

We are currently on mui v4 / jss and have been looking at upgrade path for a while.

Our expectation was to switch to mui v6/7 which supports new runtime-free css engine - but looks like mui7 out last week is still sticking with emotion.

The whole pigment css saga has been disappointing. When this was announced over an year ago, there were many asking the need for a separate styling lib instead of adopting stylex / griffel (developing a new styling solution is really hard) but there were apparent benefits with the proposed solution.

Now since 1 year of announcement, there is no proper release / upgrade path yet for pigment and looks like it is undergoing major refactor for v1?

Meanwhile, Base UI, which got release, while impressive, doesn't even mention Pigment CSS.

There is not even a website since an year this was announced, where an llm can generate one in 10 mins these days.

In this day of React 19 + RSCs + Shadcn + Tailwind, does the team still expect pigment css to be THE future at MUI?

Search keywords:

[oliviertassinari]

Base UI, which got release, while impressive, doesn't even mention Pigment CSS.

@aarjithn Pigment CSS is currently experimental, e.g. https://mui.com/material-ui/experimental-api/pigment-css/. Its latest version is 0.0.30.

The problem is that it's not mature enough to be documented in Base UI or used there. At the root, we have those 3 problems with it:

1. The build time is too slow. We tried to migrate https://mui.com/store/ from Emotion to Pigment CSS but ended up being too slow. Internal PR: https://github.com/mui/mui-private/pull/552 and https://github.com/mui/mui-private/pull/511. This needs a rework to have faster build times. We need the docs to use it by default to know if it's fast enough.
2. Integration with Next.js and Vite has been really unstable. People have faced a lot of issues. The worst part is in the debuggability. We have made little progress with it.
3. A missing story for bundlers that don't have an integration with. This is the biggest problem for me. We have to support all bundlers in Material UI, we can't have a style engine that only works for some bundlers. We have only two options here:

• Pigment CSS has a strong raw CSS file output
• Pigment CSS has a runtime as a fallback

Technically, I think that if we were to invest enough resources, those are solvable problems.

Now since 1 year of announcement, there is no proper release / upgrade path yet for pigment and looks like it is undergoing major mui/pigment-css#362 for v1?

For people who want to try this experimental API, we have https://mui.com/material-ui/migration/migrating-to-pigment-css/ (it's in the wrong place of the docs).

Those major changes are driven by the need to fix 1. 2. 3.

There is not even a website since an year this was announced, where an llm can generate one in 10 mins these days.

There is a WIP version in https://deploy-preview-378--pigment-css.netlify.app/overview/quick-start. From mui/pigment-css#378. cc @brijeshb42

Our expectation was to switch to mui v6/7 which supports new runtime-free css engine

Is your main challenge with Emotion performance or RSC?

In this day of React 19 + RSCs + Shadcn + Tailwind, does the team still expect pigment css to be THE future at MUI?

In the current trajectory Pigment CSS is in, it feels like we would need a miracle to fix 1., 2., 3. soon enough to be used in the next major of Material UI, so I don't think it's realistic.

If we go back to why we work on Pigment CSS #38137 (comment), it increasingly looks like to improve runtime performance and RSC support, we have to let go of the "no breaking changes" constraint, this will take more breaking changes than we hopped for. This also means that the "raw CSS" option is also now on the table.

As for the next major of Material UI, we have been going back to the drawing board, reviewing all the options to fix RSC and performance.

In the long-term, I do believe that there is an opportunity for Pigment CSS to emerge as a great style solution, but it's a long road. We might or might not be able to make it.

[jimmycallin]

@oliviertassinari Thanks for the update. While you’re still figuring things out, I’m wondering how we can best prepare today in case a stable Pigment CSS does happen. Among the current styling options (styled, sx, className, etc.), could you provide a brief summary—without committing to anything—ranking them from most to least problematic, assuming the least problematic would cause the least friction when adopting Pigment?

[oliviertassinari]

@jimmycallin I don't expect one API to be harder to implement than the other. I think it's really a problem about: How do we scale Pigment CSS? For example, https://github.com/oliviertassinari/react-conf-2024-pigment-css worked great with Pigment CSS, but it was a simple use case.

[jimmycallin]

@oliviertassinari I see, so what is the nature of the breaking changes you mentioned?

[aarjithn]

Thanks for the detailed reply @oliviertassinari - the challenges faced are very understandable, building a new CSS styling framework is hard, especially the direction React is going with RSC era. One of the pioneers Styled components have entered maintenance mode.

Given that some of the original goals seen very difficult to attain (like no breaking changes) do you think it might make sense to refocus the efforts onto stylex or Griffel which already has bundler integrations and also most of infrastructure?

That is, now that pigment is uncertain, is the expectation that MUI sticks with emotion for foreseeable future?

Emotion, while as you say 'works' - I don't know should be the first choice of styling when we build a new app in this era, and believe would be a turnoff for greenfield apps.

I think the uncertainty around this doesn't help MUI especially when Shadcn + Tailwind sort of becoming defacto standard with all of AI code-gen.

[JanStevens]

Maybe a bit off topic but making your own zero runtime solution is so hard why reinvent the wheel?

I understand that braking changings are annoying but this now prevents progress making mui lag behind.

If braking changes are always going to be there why not look at existing solutions and incorporate that? Ex https://yak.js.org/docs/migration-from-styled-components has 90% feature parity with styles components and is rust based and fast.

My two cents is that the eco system is rapidly moving away from css in js solution and mui is now stuck with no way forward. Even the creator of styled components has not used it in production in the last 5 years (https://opencollective.com/styled-components/updates/thank-you)

I'm a big fan of mui, always used it but for my next greenfield project I can't justify using it anymore sadly.

Regards

[abriginets]

we have to let go of the "no breaking changes" constraint, this will take more breaking changes than we hopped for

This cannot be avoided unfortunately. I know people complained a lot about how difficult it was to upgrade from v4 to v5, but this case is simply incomparable to the current situation. React introduced RSC and NextJS introduced app dir in order to support it, and it was obvious that everybody else had to go over major refactoring too in order to comply with the newest paradigm.

We spent 7 months rewriting our entire NextJS app built on top of pages dir. During that time we had literally 0 features delivered due to this process. This was a conscious decision because we knew that performance from both zero-runtime styling solution and RSC in our highly competitive niche was very important - for both SEO and end users.

IMO it doesn't matter how many breaking changes there are on MUI side anymore. People would still have to rewrite A LOT because of the new paradigm.