The last time we were on HN was 7 years ago with https://news.ycombinator.com/item?id=8582439! Back then, the community got hooked up in the integration of two shiny new trends: React and Material Design. A lot has changed in the React community since then.

In v5, we have focused on improving the customization experience, making the components as flexible as possible. You can find the following improvements:

- We have a new rebrand that distinguishes ourselves from Material Design: https://mui.com/blog/material-ui-is-now-mui/.

- We have moved from JSS to emotion, using the styled-components API as a primitive. This was a highly requested change from the community: https://github.com/mui-org/material-ui/issues/6115

- We have introduced styling props, and a sx prop: https://mui.com/system/basics/

- We have a growing set of alpha unstyled components, e.g. https://mui.com/components/autocomplete/#useautocomplete

- We have incorporated a company, sustaining over 10 people.

- We have introduced an advanced data grid: https://mui.com/components/data-grid/demo/

Thanks!

Also, I was surprised how well the codemod worked with the migration to v5. I've migrated a large code base and almost didn't have to do anything.

The only thing I'm not a big fan of is that using the new 'sx' prop, the styling becomes very specific to the library. But I guess it's more of an issue with the fragmented state of styling in react. I think it'll stick with the 'styled' api since it's more generic.

Great job and thank you!

- Custom styling with JSS was an underdocumented nightmare

- The Grid system had many gotchas, especially with flexible columns in flexbox

- "Private" components had to be used or replaced in Table components to enable sorting

- JSS generated classnames changed if you included material-ui-based components in a separate library

I'm not really trying to harp on the developers here, but I've had to re-implement basically all the material-ui components I've had to use, because it was infeasible to update the library due to the amount of changes required.

I got the value of JSX even if it felt messy - but the css-in-js becoming popular on frontend is one of the why I switched to full backend roles now.

And when he says that changing the implementation of a styling solution improves component performance 5x ... at what point is it OK for a fancy styling abstraction layer that serves no real purpose (it was just as shit to customise as any other solution, doubt it made people significantly more productive, and they said it was a maintenance burden to maintain abstraction layers) suck up that much performance ? Even the "fast" path is order of magnitude slower compared to good old CSS...

Material-UI v3 had an issue (which I think v4 and v5 probably still have?) where CSS-in-JS winds up retranslating Javascript blocks into CSS and adding them to every SSR, and then retranslating them again on the client as part of the pageload, which wasn't performant enough for us. So we set up a system where we would pregenerate a static stylesheet with deterministic names, and serve that as a cacheable resource. Then v4 comes along and all of the CSS-in-JS related wiring is different, so our static stylesheet thing would have to be rewritten, and then v5 comes along and it's been redone again, and it doesn't look like I want to touch this without some signal that it's stabilized.

[1] https://home.miui.com/