[data grid] Add support for Joy UI

[oliviertassinari]

Summary 💡

Allow user to easily set up a Joy design on their data grid components.

Examples of users needing this

• https://mui.zendesk.com/agent/tickets/14304 "We are evaluating changing our internal tooling for a combination of Joy UI + the Datagrid Pro version"
• [data grid] Page fails to load DataGrid with Joy UI #7636

Solution exploration

• DataGrid - Joy UI integration #6811
• [RFC] Extract Material UI from internal DataGrid APIs  #7100

[chyzwar]

Do you plan to work on Joy design support for mui-x v7 ? I working on new application that use joy-ui and I am trying to understand if mui-x will be viable option for DataGrid.

[oliviertassinari]

@chyzwar there are no plans to improve Joy UI support in MUI X v7. However, it's possible to have a Joy UI data grid for you by replacing slots and restyling elements.

This workaround comes with downsides:

1. It's time consuming
2. The execution doesn't benefit from network effects (open source contribution polishes and fixes)
3. Material UI stays in the bundle

Because developers can't do anything about 3. I think it's the first problem we should solve, this is #10143.

Once solved, then I think we could solve 1. and 2 by having a built-in default style layer, which this issue is about.

[chyzwar]

Thank you for letting me know about future plans. I will go with workaround and re-style DataGrid to match joy-ui.

For me, Joy-UI is great because it is share high quality underlying implementation with material-ui without obnoxious design of material design. I see that material-ui team is doing now much more (base-ui, mui-x, md v3, zero runtime) I hope that Joy will not get neglected.

[oliviertassinari]

Joy-UI is great because it is share high quality underlying implementation with material-ui without obnoxious design of material design

@chyzwar I'm 💯 aligned with this. I have a friend who uses Joy UI over Material UI because of this. It's also why I would use Joy UI.

Work on Joy UI is right now delayed https://mui.com/blog/2023-material-ui-v6-and-beyond/#a-sharper-focus. This is because of https://npm-stat.com/charts.html?package=%40mui%2Fjoy&from=2022-02-01&to=2024-02-01, there is not enough developer traction relative to its opportunity cost, I think we learned that for Joy UI to work, we need a larger team on it but at the same time we are clearly spread too thin with Material UI, not enough R&D spent on it, it's lagging. Material UI is no longer held back by Material Design as when we started the effort on Joy UI (but helped back by the same things that hold Joy UI back), so we refocused the effort on Material UI to solve these problems. Meaning the judgment call is that right now, there is more ROI on time spent on Material UI than Joy UI.

The good news: we doubled the Core team ~6 months month ago, and are hiring to double this product group again. I suspect this will give us enough bandwidth to cover the scope of Joy UI but this time stand out with more focus and having the main bottlenecks we identified solved.

However, from a developer standpoint, we will likely have Joy UI and Material UI API a lot closer, differentiating with the default look & feel for end-users. I would expect breaking changes.

Speaking under @siriwatknp's control, this is how I understand the situation.

[kamavingah]

Adding a link to mui/material-ui#29024 (reply in thread) since it's relevant to this issue