Can the typings be simplified to improve performance?

As suggested by @eps1lon in #18128, I’m creating this issue as a place to discuss the Material-UI typings and whether they can be simplified to reduce the amount of time spent checking them, especially during editing.

There’s always a tension between having the most exact types (which provide the best errors and editor completions) and having the fast type checking (the far end of the spectrum being any).
Issues like https://github.com/microsoft/TypeScript/issues/34801 suggest that Material-UI might benefit from relaxing the exactness in order to gain back some perf.

From the repros I’ve investigated so far, a lot of the slowness seems to come from the large number of CSS property names (see https://github.com/mui-org/material-ui/blob/master/packages/material-ui-styles/src/withStyles/withStyles.d.ts). Not being an active CSS user myself, I have some naive questions:

1. Am I correct in assuming that having a name and type for each well-known CSS property is incredibly valuable and isn’t something we could give up?
2. The CSSProperties type appears to exist to support “pseudo selectors and media queries”, which - according to my limited reading - seem to be named bags of additional CSS properties. a) Are these bags themselves recursive or is there only a single additional layer? That is, do you go from width to foo.width or to foo.bar.width, etc? If it’s just one level, simplifying the types cuts my local repro from 4.6 seconds down to 3.6 seconds (i.e. big win). b) I played around with the types myself and couldn’t come up with anything better than BaseCSSProperties[keyof BaseCSSProperties], but - as I’m guessing you’re aware - that’s not a very useful type. It basically says that any CSS property can have the type of any (other) CSS property - that’s only slightly better than any.
3. In StyleRules, if there are no properties, you get either CSSProperties or () => CSSProperties (which I will sloppily call “thunked CSSProperties”), which makes sense - the CSSProperties might be lazy. If there are properties, you get either CreateCSSProperties<Props>, which makes sense - the Props might be required to compute the CSSProperties - or (props: Props) => CreateCSSProperties<Props>, which I didn’t understand because it’s effectively double-lazy - you have pass in the Props once to get the CreateCSSProperties and then again to get individual properties. Why is it “double thunked”?

Separately, I suspect, but have yet to demonstrate that IsEmptyInterface is too expensive for the benefit it provides. However, it’s quite possible that I don’t fully understand the benefits, so it would helpful to hear more.

Can we work together to find the right balance between accuracy and perf? (Note: “just make the compiler faster” is obviously a viable strategy, but I’d like to get the typings to a good place before we optimize for them.) Thanks!

Pains

• https://www.reddit.com/r/reactjs/comments/tauog2/mantine_40_is_out_120_hooks_and_components_with/i045u2l/
• https://www.reddit.com/r/reactjs/comments/sbrjxs/choosing_the_right_component_library_for_your/hu1tqmy/

[oliviertassinari]

88 upvotes on this comment: https://www.reddit.com/r/reactjs/comments/sbrjxs/choosing_the_right_component_library_for_your/hu1tqmy/

MUI with typescript is a nightmare right now. It literally takes more than 3-4 seconds for autocomplete or IntelliSense to show up. And this problem has not been solved since 2019.

We need to change something.

[ChuckJonas]

Has there been any progress on this? Material-UI v5 is borderline unusable due to this.