Too many style frameworks?

[krassowski]

jupyterlab-git uses:

• typestyle
• mui
• native CSS

This has performance implications because we get a lot of CSS rules of various quality.

typestyle is really a mixed bag:

• good because it prevents unused styles from lingering,
• provides some checks (but we can get this in plain CSS with stylelint),
• is good/neutral in performance terms (tailored classes are good)
• is hard to debug, and to profile with ui-profiler
• is hard to override in themes (which is not a huge deal if variables are used widely, but then overuse of variables has performance implications).

I do not have a strong opinion on mui yet but I suspect there are limits to what it can do.

It would be good to consider some guidelines on what future code should use to minimise confusion and get the best performance (for example #1264 adds more typestyle).

[fcollonval]

@Zxun2 if you want to work on this one, I would start by switching components from MaterialUI to the Jupyter toolkit when there is a replacement available (like tab panel, buttons, dialog, input,...). When replacing components, remove the associated CSS-in-JS class(es) and add well defined CSS class name(s) with as few rules as possible (mostly positioning rules as the toolkit should give you well integrated font and color rules).

Some notes on the toolkit:

• you will need to use @jupyter/react-components to get the web components provided by the toolkit wrap in React components. The naming is generally straighforward. In the storybook, open the code snippet for a component. The react component name will be the web component name without the prefix jp- and capitalize.
• to apply automatically the JupyterLab theme to the Jupyter toolkit, you will need to call the function addJupyterLabThemeChangeListener in this extension

[krassowski]

(feel free to ping me for a final review to check for performance-related CSS issues)