The background of MUI v5 (part1)

Improved customizability

Migration from JSS to emotion

The first step we took to improve the customization experience was to rethink the styling solution from a blank page.

If you have been following MUI for a long time, you have probably noticed that we have iterated (a lot!) on the styling solution over the last seven years. 

Originally it was Less, then inline-styles, then JSS, and now emotion. Why change it again? We wanted to solve the following problems:

This was to solve following problems 

The React community is settling on styled() as the most popular CSS-in-JS API. We have used popularity as a proxy for "best".

const StyledDiv = styled('div')({

  color: 'red',

});

// or

const StyledDiv = styled.div`

  color: red;

`;

We have made styled() the lowest level primitive to add styles. This API is already known by many.

We have defined a common interface with concrete implementations:

@mui/styled-engine: implemented with emotion (default).

@mui/styled-engine-sc: implemented with styled-components

If you are using a different styling library, feel free to contribute a wrapper. For instance, there is one attempt with goober, a library obsessing on bundle size (3kB gzipped).

This allows developers to swap between different style engines. For example, styled-components users no longer need to bundle emotion and styled-component, nor do they need to configure the server-side rendering for each. How does the swap work? The same way it does from React to Preact.

The first immediate benefit of the move to emotion was performance. The <Box> component is x5-x10 more performant in v5, compared to v4.

Going forward, developers can either keep using JSS with the legacy @mui/styles package or migrate from JSS. We recommend the latter to match the core components.

references:

https://mui.com/blog/mui-core-v5/#high-level-goals-for-v5