Create eject CLI to move from Material UI / Joy UI to Base UI

Summary 💡

This issue is exploring the idea of allowing developers to automatically eject from Material UI / Joy UI, effectively going one level down in the abstraction to have the source in your codebase, while using Base UI, and the styling solution of your choice (either MUI System, or Tailwind CSS, or CSS Modules)

https://github.com/mui/material-ui/assets/3165635/777e9590-6f5b-454e-a88a-a98e4aacff32

Benchmarks

Tailwind UI first illustrated the value of this approach
Shadcn UI later confirmed it
https://raw.tremor.so/docs/getting-started/installation
https://github.com/cschroeter/park-ui

Motivation 🔦

Today, the most popular way for engineers to create their design system is to create them by themselves:

https://tsh.io/state-of-frontend/

Why is that? Isn't this such a massive amount of wasted effort? I think that https://andrewingram.net/posts/recipe-kits-a-great-alternative-to-installable-libraries might be into why this is happening:

I’m perfectly capable of building all the necessary components from scratch, but that’ll slow me down from building what I’m actually here to build

So first, because UI elements are only one part of the UI, most developers have the skill to create these elements (modulo the design skills which is a big limiting factor).

Dependencies that align with what I’m already using. This is a tricky one, but I likely already have a favored set of dependencies for things like animation, headless UI, styling, and so on. So if my choice of component library brings in a heap of different (but equivalent) dependencies, that’s a waste.

Second, for the same reason as in the first one, the design system is a continuation of the rest of your app, you want to use the same technologies.

For example, CSS styling is a highly fragmented ecosystem: https://2022.stateofcss.com/en-US/css-in-js/.

Customisable, without bloat. Quite often, 3rd party components suffer from either being too customisable or not customisable enough. Too customisable means we’re paying a file size cost for functionality we’ll likely never use. Too little power to customise and we find ourself working around the components rather than with them.

Third, the amount of distrust engineers have in UI libraries when it comes to CSS customization, never really feeling they are at the right level of abstraction. Which is really about this simple idea: how do you remove CSS from a UI library? Maybe because it's a customization feature you don't need that feels like bloat, or more simply a CSS property that doesn't default you try to remove.

The solution seems simple: MUI builds an ejection script that allows developers to move the styles to their codebase, leaving developers full access to the CSS and the styling engine of their preference. This is part of why we focused on creating Base UI: #6218.

It's to be noted that this also directly linked to #37222 as it covers how Base UI demos could be switched between using different style engines and different default themes (Material Design / Joy Design).

mui / material-ui