[system] Support new style engine that generates static CSS files at build time

[oalexdoda]

(issue heavily edited by @oliviertassinari)

Summary 💡

I recently found an article that breaks down in detail why CSS-in-JS doesn't have the best performance https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b. One of the core features I'm using with MUI is the sx / Emotion / CSS-in-JS feature.

This is a proposal to provide a new style engine inspired by the zero-runtime CSS-in-JS libraries: extract all the CSS-in-JS, split it into CSS modules when building the app for production, and serve the styles that way instead. The goal is to retain as much as possible of the current API while having no runtime.

There should be as few breaking changes as possible, and provide a progressive migration story. We wouldn't deprecate the other style engines.

Examples 🌈

• https://vanilla-extract.style/
• https://linaria.dev/
• https://compiledcssinjs.com/

Motivation 🔦

The current CSS-in-JS runtimes:

1. takes more CPU cycles to add the styles than raw CSS would take.
2. increases bundle size
3. are not compatible with react server component Plans to support Next.js 13 - /app directory emotion-js/emotion#2928 Nextjs 13 styled-components/styled-components#3856 and might never be Improve Next.js support #34905 (comment) Add React Server Component support for Layout components (Grid, Stack, Container) #35993
4. don't work well with Next.js v13

We have seen developers use Tailwind CSS because they are afraid that Material UI is not fast enough. But by moving, they get, what we could argue is a poorer DX with the utility CSS class name. The problems a. you unlearn CSS with utility classes, b. the utility classes are harder to use for conditional styling.

Also, this example shows that it's all about the perception of performance and not the actual performance. Having no runtime would make it very clear that the performance should "logically" be equivalent.

What success looks like?

Two ways to quantify success in this effort:

• Runtime. Use the benchmark in Bad material-ui Box performance #21657 (comment). We should aim toward another x3 to x8 in the runtime of MUI System v6 compared to v5 (when v5 was ~x3 faster than v4).

• Bundlesize. Material UI with emotion + its client-side components + its theme adds ~25k gzipped of JavaScript vs. Tailwind CSS.

  • Tailwind CSS with the app directory and a simple page: https://github.com/vercel/next.js/tree/canary/examples/with-tailwindcss: 80.8 kB gzipped
  • Material UI with the pages directory and a simple page: https://github.com/mui/material-ui/tree/master/examples/material-next 104 kB gzipped

Benchmarks

• https://cakepop-docs.vercel.app/pop/usage, using https://github.com/wayfair/rainbow-sprinkles behind the scene.

[oalexdoda]

Some ideas:

• https://vanilla-extract.style/
• https://linaria.dev/
• https://compiledcssinjs.com/

Any way to get something like this in MUI natively?

[oliviertassinari]

It would be awesome to move to a static extraction styled() API. I'm adding it as a feature candidate for Material UI v6: #30660.

The biggest challenges would likely be:

1. How to deliver the same great DX?
2. How to make the amount of breaking changes acceptable? We should keep most of the existing API and make it a progressive migration.

The solution could be to make this runtime-less a "mode". Meaning something that developers can progressively migrate to. Typically when they want to benefit from RSC (#35993).

---

Other ideas:

• We could look deeper into Goober https://github.com/cristianbote/goober. It might save us > 5kB gzipped of bundle size. The runtime benchmark in https://github.com/cristianbote/goober#ssr-1 suggests that on the server, we could handle dynamic requests x2 faster. The performance on the client side might be better too: https://twind.dev/handbook/introduction.html#benchmarks. I started to look at it a year ago: [styled-engine] Add support for goober #27776.
• We could also rewrite the MUI System implementation, it's slower than it needs to be.

The end goal is to get points c. and d. as close as possible to a.

https://mui.com/system/getting-started/usage/#performance-tradeoffs.

To be fair, d. seems good enough in most cases. It's usually not good enough when you have a large DOM, at which point, you need to rewrite a bit how the styles are applied, which costs you time.

If you open https://pagespeed.web.dev/report?url=https%3A%2F%2Fmui.com%2F&form_factor=mobile, it's not "insanely great" as would say Steve Jobs, this would likely help.

Plus, Server-side React Component could help a lot, for which, we need MUI System to be compatible with #35993. Success would like having 100/100 in:

https://pagespeed.web.dev/analysis/https-mui-com/z9cmpqb6ka?form_factor=desktop

[saad12035]

@altechzilla I would recommend that instead of using sx with the components create a separate file and use makestyles for HTML semantics and styled for MUI components.
In this way you can reuse a styled component in anywhere in your project instead of redefining it and it also helps in a way that
with every reload of the page your inline styling will not be rendered and you can always apply lazy loading on the components which are less important.

[mnajdova]

I think that exploring https://github.com/cristianbote/goober could also be great, it could already yield a great improvement see the benchmark https://twind.dev/handbook/introduction.html#benchmarks.

Agree, I remember we discussed this in the past, maybe even trying with a custom styled-engine adapter to be optionally added (and if it proves to be success we can promote this adapter as a default). I could try to create a dirty poc soon about this.

We could also rewrite the MUI System implementation, it's slower than it needs to be.

👍 we could actually start investigating this in Q1 2023

Another idea would be to use a utility classes for the sx prop, meaning we can keep the same object syntax, but transform each key value pair to a utility class. We are likely going to need to drop some of the functionality it has but it could be a start. Developers can then also use the className prop instead of sx. I remember we started investigating this two years ago, but from what I remember back then we didn't pursue with it because developers would need to load additional css in their project statically.

[oliviertassinari]

Goober was explored a bit in #27776

[mnajdova]

Goober was explored a bit in #27776

Thanks for linking it, I will check to see what was missing

[oalexdoda]

Kinda wish Emotion was optional to some degree to avoid complexity and issues like:
#34910
vercel/turborepo#2312 (comment)

[dohomi]

It would be great if MUI styles would rely entirely on css class composition (as mentioned in #34826 (comment)), similar like DaisyUI build with Tailwind. That could power different themes like Material UI, Joy UI customised with different CSSVars