Yes, this is the plan and how it is current designed.

There was also discussion on making it agnostic to React.

I hope so too

This is a great point. We can look into creating an example project and show how it can work.

Super

Yes. We are already moving ahead with zero-runtime. Nostylex usage, atleast in@mui/material.

Thank you for the clarification! We should avoid getting back to pros and cons to keep this focused on the actual scope.

Thank you, I understand too

Thanks for the explanation! Interestingly, even with 15K calls on the runtime page, it only works 15ms. Have you noticed any features when scaling to larger components or when using style compositions more complex?

I think the dream would be:

1. to support thesx prop on any component, host element too (span, h1, etc.)
2. to trend toward removing the Box primitive, since 1. covers the same use case. It might take a while though, because removing Box should probably only happen after emotion is no longer a runtime, which could never happen.

Yes, the idea with sx on any component really makes Box less needed. I wonder how you see the transition from Box to this approach for large code bases – will there be any migration tools when emotions stop being runtime?

Yes, it's really expected! 😅 I hope that with this change streaming SSR will become real without big crutches.

Looks like what we basically need is a method that takes in a nested object and returns an object of classnames:

MUI v4:

constuseStyles=makeStyles((theme)=>({title:{color:theme.palette.primary.main,}}));functionApp(){constclasses=useStyles();return<divclassName={classes.title}>Iaminvisible</div>;}

Pigment css API:

consttitle=css(({ theme})=>({color:theme.colors.primary,fontSize:theme.spacing.unit*4,fontFamily:theme.typography.fontFamily,}));functionApp(){return<divclassName={title}>Iaminvisible</div>;}

Proposed new "makestyles"

conststyles=makeStyles(({theme})=>({title:{color:theme.colors.primary}}))functionApp(){return<divclassName={styles.title}>Iaminvisible</div>;}

There could be some minor differences like if response can be used directly without hook as in v4, but still it should be mostly easy to migrate@brijeshb42 what do you think?

Thee is no plan to support the makeStyles API today. Until we can demonstrate that Pigment CSS works, this looks like a distraction. JSS continues to work.

Of course, thanks for the explanation. It is logical to first prove that Pigment CSS works stably before considering makeStyles.

Let's move this to a separate issue.

Pigment works by injecting a Webpack plugin into the next config. So as of right now, we won't be able to support turbo till it's atleast not experimental or it exposes a way to have plugins.

We might want to create an issue for this, it looks equivalent tofacebook/stylex#63.

@brijeshb42, issue created:https://github.com/mui/material-ui/issues/41449
@oliviertassinari, I don't think these issues are equivalent. That issue looks like it's regarding Turborepo, not Turbopack. Turborepo and Turbopack are in the same repo and related though.

Understood, thanks for the explanation! Then it is logical that Turbo support is postponed until there is a stable way to add plugins.

I think, mui v6 is on the way for that

There is no official guide for migrating MUI 5 to Pigment zero runtime yet, but it is logical to start with the components that are least dependent on JSS or makeStyles. Then gradually replace the styles with Pigment CSS via sx or styled API.

Could you expand on what would be the value of the style prop ? Any arbitrary example works?

Please understand that I'm coming from this as a layman. I don't understand the inner workings of these new css libraries.

The value proposition would be that the inital css is overwritten by a prop.

A quick example would be something like:

import{css,prop}from"@pigment-css/react";import{CSSProperties}from"react";constbaseStyles=css({color:"red",background:"white",fontWeight:"normal",});interfacecustomComponentProps{propStyle:CSSProperties}functionCustomComponent({ propStyle}:customComponentProps){return(<div{...prop(baseStyles,propStyle)}>      some text</div>)}

The result is that the CustomComponent can have certain styles added and overriden.

exportfunctionPage(){conststyle={color:"green",fontWeight:"bold","&:hover":{color:"blue"}}return(<CustomComponentpropStyle={style}/>)}

Unfortunately, this does not translate to my POC. It's vastly more complicated.

An example of my poc.

I'm instantiating the components via the styled api:

badge.css.ts

import { styled } from "@pigment-css/react";import { Box as RaikouBox } from "@raikou/core";export const Box = styled(RaikouBox)((props) => ({  background: "orange",}));export const Section = styled("span")((props) => ({  color: "green",}));export const Label = styled("span")((props) => ({  color: "black",}));

Badge.tsx (as a package)t:

import { Box, Section, Label } from "./Badge.css";...export const Badge = polymorphicFactory<BadgeFactory>((_props, ref) => {...return (    <Box      variant={variant}      mod={{ block: fullWidth }}      ref={ref}      {...others}    >      {leftSection && (        <Section          data-position="left"          sx={{            background: "red",          }}        >          {leftSection}        </Section>      )}      <Label>{children}</Label>      {rightSection && (        <Section data-position="right">          {rightSection}        </Section>      )}    </Box>  );});

The problem I have using thecss function. I'm unable to pass it any props. So instead I'm using styled api. I should be able to overwrite the styles? But using SX prop here I'm unable to do so. Also I tried the runtime example above, again wasn't able to get it working.

Btw, this was a test to see what was possible. As I'm still new to the library.

My actual use case is something like:

classNames.section is an object of styles.

<Section data-position="left" sx={...classNames.section}>   {leftSection}</Section>

As the component would be used in this manner:

import { Badge } from "@raikou/server";export default function Page() {  return (    <Badge      classNames={{        root: {          color: "purple",        },        section: {          background: "red"        }      }}      leftSection="$$"    >      hello    </Badge>  );}

Hopefully this makes more sense now?

Oh to clarify as well. All the values passed are static. None of them are dependent on props themselves. So this is all focused on buildtime.

I'd say this is more suited when atomic css is involved, since here, you'd want to followstylex's principle of last passed style always gets applied instead of last defined styles which would require deduping classnames of similar css properties. Current or near future implementation of Pigment CSS won't be solving for this particular use-case.

@brijeshb42 Alright, good to know! Many thanks!

One of my aspirations for my own tech stack is at scale to not break the bank in production. So if I can reduce the css payload significantly. I'm all for it.

@paulm17 Pigment CSS relies on CSS Modules, CSS Modules can be code-split by the bundler based on what's visible on the screen. These CSS files can also be removed from the DOM when moving to a different page.

Atomic CSS shines when you have large CSS files and you don't code-split.
For example, we can compare facebook.com StyleX CSS file, they style the whole app with it:

withhttps://vercel.com homepage, it's written with CSS Modules:

The difference isn't that significant with Next.js. For example withhttps://vitejs.dev/guide/features.html#css-code-splitting it might work even better.

Now, we could consider an atomic CSS mode in the future, like even with CSS Modules code split, it could bring another level of performance in addition to code splitting.

Good question! From what I understand, atomic styles might be planned for a future release, but nothing official has been mentioned yet.

I dont think im explaining it very well.

So in our app.jsx we make a call like this, in which we create a theme object with various values from Runtime that are passed down to the app.jsx via props. Rough example below

const theme = createTheme({  pallette: {    primary: {      main: props.dbValue,    },    secondary: {      main: props.dbValue,    }  },});

We then pass this runtime theme to theThemeProvider with the following example:

<ThemeProvider theme={theme}>  <MyCustomComponent /></ThemeProvider>

Then when we use any MUI component it will naturally pull in the Runtime Primary/Secondary colors automatically. If we have some components that wrap MUI components or that useStyled() we again have access to this runtime variable.

1. How do we override the theme create in the config with runtime values and have that trickle down to all the nested MUI components? is there like anUpdateTheme() hook?
2. Can we use the same<ThemeProvider> and subsequentuseTheme

@brijeshb42 any update to my last comment?

You can easily do so using a<style> tag in your document head. You can fetch your theme config from backend and override CSS variables either using inline style on adiv or you can create a dynamic css and append it to thehead tag at runtime like -

constcss=`  --palette-primary-main:${backend.value.primary.main}  /* similarly set other variable values */`;

// on CSR appsconststyle=document.createElement('style')document.head.appendChild(style)

// on SSR apps<style>{css}</style>

We'll also be providing an export from@pigment-css/react to help you do the same. But it's not there right now as we are still ideating it.

Awesome that's for the info and examples. Also just a shout out to all the hard work you guys have done getting pigment off the ground. Can't wait to start using it more in our MUI based areas/apps

Totally agree! Huge kudos to the team for getting Pigment off the ground. Excited to see it in action in MUI apps!

Absolutely! The css prop is super powerful—it gives the utility of Tailwind while letting us write more natural CSS. Definitely don’t want it forgotten.

Heya@kxseilerjo. I'm not sure we can say the details yet, as we're primarily focused on converting Material UI components for now. Generally speaking, we'll return the focus to Joy UI together with the Material UI v7 cycle. We'll iron out the Material UI <> Joy UI and Joy UI <> Pigment CSS relationship then.

Great question! I’m also curious how this ties into Joy, especially with the push to rely on CSS variables. Will Pigment fully integrate with that approach or are there trade-offs?

I read that eventually you are moving completely to pigment, which I can understand why for apps that are completely built at run time.

So, does that mean that this use case will be completely unsupported by MUI in the future?

You could probably set the dynamic settings as css vars instead and have it set values in runtime - that should work

I am not sure I understand this 100%. From the examples I have seen, I would have to define all possible css vars to be able to use the same system as I am using now.

Because I don't know which css vars will be needed at build time for a Box component, for example. There could be none, 1, 2, etc. for each instance of the Box component. Meaning they could all be different.

Maybe I am misunderstanding how it would be implemented.

I just wanted to add the explanation for why I am doing things this way, in case it helps to understand it.

The main reason I am doing this is that it allows me to change a client's app without needing to do a redeployment of the code base, which might introduce bugs for other tenants.

And because no deployment is needed, I can make changes and iterate very quickly which gives a much better outcome for the client. It makes for very slightly slower app performance, but it is much faster in terms of making changes.

So for a box lets say you change padding, margin, boxShadow, borderRadius for eg. define all these with standard values at build time. and change it in runtime. It's a chore to define all possible properties for sure, but if you can limit it might be manageable.