Material-UI is releasing v5 and rebrands to mui.com(mui.com)
mui.com
Material-UI is releasing v5 and rebrands to mui.com
https://mui.com/blog/mui-core-v5/
14 comments
[deleted]
You don't have screenshots or a "widget tree".
I absolutely love this library. I've used several ui toolkits before, and mui is my favorite. It's consistent, very well made, focused on react and responsible with not introducing unexpected breaking changes (unlike another popular library which I used to use).
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!
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!
Having used Material UI in the turbulent days of v1, I can't say I've had a good experience.
- 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.
- 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.
Reading through the styling part and working with mui4 and other widget libraries in the past - and seeing the 5 solutions listed that basically do the same thing - holly shit how did it get to this point...
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...
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...
I'm not familiar with JSS, but styled-components works by creating a whole new React component for each layer of styling that you'd traditionally use a CSS class for. And despite appearances React components aren't just function calls, they're persistent objects that carry their own overhead. So doing things this way seriously inflates the work that has to happen at runtime.
Using "plain styles" in a component-oriented architecture relies on convention more than I'd like it to, but... the cost of the CSS-in-JS solutions I've seen just seems too high to be worth it. I don't know what the solution is.
Using "plain styles" in a component-oriented architecture relies on convention more than I'd like it to, but... the cost of the CSS-in-JS solutions I've seen just seems too high to be worth it. I don't know what the solution is.
I think Material UI (and the whole ecosystem of Javascript libraries of which it's a part) are drastically underestimating the costs that churn imposes on their users. I say this as a developer of a codebase currently on material-UI v3, looking at v4 and v5, having bounced off the task of upgrading a few times and currently thinking it's probably not worth it.
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.
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.
I really like the theme you are using for the new documentation and the customized themed components you are showing on the landing page https://mui.com/. Are these themes publicly available somewhere?
When I read this quicly I thought 'Material-UI is merging with Xiaomi's MIUI [1]' - and I suspect I will not be the only one making this mistake...
[1] https://home.miui.com/
[1] https://home.miui.com/
MUI is really awesome to use.
I wonder how easy it will be to migrate from v4!
There's a codemod [1] to automate most of the code changes needed, and a comprehensive migration guide [2].
[1] https://mui.com/guides/migration-v4/#preset-safe
[2] https://mui.com/guides/migration-v4/
Feedback so far has been positive...
[1] https://mui.com/guides/migration-v4/#preset-safe
[2] https://mui.com/guides/migration-v4/
Feedback so far has been positive...
[deleted]
There's already a UI toolkit called MUI: "Magic User Interface" for Amiga relevant 'just' some 20-30 years ago :)
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!