DEV Community

loading...
Cover image for Why you should NOT use Material-UI

Why you should NOT use Material-UI

gaelferrand profile image GaelFerrand ・5 min read

Alt Text

Introduction

Material-UI is a popular components library (a competitor of Reactstrap that unifies React and Material Design, the design system built by Google.

As a React developer I've used Material-UI in countless projets and I must say that it's a great library that comes with its grid system, lots of components, and helps build consistent UIs quite fast.

I was pretty happy with it until I used it for my personnal open-source project Ammo.

Quick parenthesis about Ammo: it's an open source projects which aims at capturing http requests and turn them into stress test engines scripts (such as Gatling). Not the focus of this article though, I won't dive into more details.

Context

Before exposing my unhappiness with Material-UI, let's get a look at my struggle.

In Ammo, I have a list of items that looks like the following :
Ammo's list of items

Each item in the list can be collapsed / uncollapsed :
Uncollapsed item

As you can see here, when uncollapsed an item reveals a few things, but nothing too fancy nor complicated. On the left, we can oberve basic HTML divs with text, and on the right we have code snippets (formatted / prettified thanks to React syntax highlighter).

Yet, I would very quickly notice that the overall performance of the application is absolutely terrible.

What?

A first set of measures

After developping the code-snippets-highlighting feature, just for the sake of being 100% happy with the feature, I tried to throw a couple items in my list and confirm that the syntax highlighting library did not tear down the performance of the app.

The idea proved to be relevant as the performance turned out to be horrible.

Just to illustrate how bad it was, here is a gif of what happend when adding 50 items to the interface (using a setInterval, adding 1 item every 300ms) :

ammo_lag

As you can see, the application is lagging like hell and a real pain to use. With just 50 items !

Coming from a gaming background, where one has to display images, animations, sound effects & musics, multiple layers of background etc. at 60FPS, seeing such a lag just for rendering HTML divs was too much to bear. So I dove into profiling.

Witch hunt: React edition

My first intuition was that there was something wrong with React. After all, I had seen (and done, let's be honest) in the past lots of apps with unnecessary renders and performance-wise poor practices. So the first thing I made was to make sure that the list was optimized, doing 2 things :

  1. Giving non-index, unique keys to each item in the list
  2. Memoize the already-rendered items so that they would not re-render when adding a new one. I used memo but useMemo is just as valid.

After that I profiled the app :
First profiling

We can notice :

  1. First of all, the memoization seems to be working very fine. We can see that the items already rendered are greyed out, meaning that they did not re-render
  2. We can see that the newly introduced item is indeed taking some render time

But what got me worried is the graph in the upper-right corner. As you can see, renders are getting slower over time. The rendering of the new item starts off taking around 100ms, but when the list gets longer, it takes up to 500ms.

What ?

First of all, why is the number of items in the list having any influence at all on the rendering time of the new item? And then, 500ms to render some basic divs! Horse crap!

Let's zoom in on the profiling of the rendering of one item :
Profiling one item
On the image I highlighted 2 things :

  1. On the right, we can see that the react-syntax-highlighter, my first source of worry, is not at all responsible for the poor performance. It renders decently fast
  2. What seems to be taking quite some time are the "headers" (on the left).

Just to be clear, this is a "header" :
Header

It's really nothing, just two inlined-texts! How come it be that slow??? Just to prove my point even further, here is the code of the <Header> component:

<Box className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</Box>
Enter fullscreen mode Exit fullscreen mode

There is litteraly nothing fancy here. No hidden performance caveheat, it's just a few basic divs!

It all comes down to Material-UI

Quite desperate, I tried lots of things, went through lots of forums, still trying to figure out how React could mess things this badly. And then, out of ideas, I naively tried to replace <Box> components with <div>:

<div className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</div>
Enter fullscreen mode Exit fullscreen mode

Stunningly, I saw some improvement in the performance! I went a bit further and tried to get rid of as much Material-UI components as possible (mostly <Box> and <Typography>) and I ended up with this :
new_profiling

If your read that right you'd see that :

  1. This test is done with 500 items (~1000 renders). And it's fluid!
  2. The highest rendering peak is at ~110ms (instead of 500ms for 50 items)
  3. The items rendering times are consistent and do not increase with the number of items in the list

ammo_fluid

So that's a big win! Now the app is decently fluid with 10 times more items! And its performance is consistent!

Conclusion

Material-UI is a great library and has had my back in the past years, yet now I would strongly advise against using it if your application might present performance challenges. A simple form or a standard web page shouldn't be a problem, but still, keep that in mind.

Of course I'm not the first one to find out about those problems, there are several issues open on Github (this one for example).

Also, after all this optimization, you could still argue that a 110ms rendering time for one item is still huge, and I'd agree, but I'll leave things here for the time being. Any further optimization shall be a good topic for a new article!

Discussion (13)

pic
Editor guide
Collapse
jtfinlay profile image
James Finlay

It's great to spread awareness of certain issues on different frameworks - I use material-ui and wasn't aware of this problem!

However, I would hesitate to call material-ui a dead end because of this. This issue looks to be resolved in the next major release. Software is an iterative process and material-ui has a strong community that puts a lot of time and effort into maintaining it. These things happen - awareness is important, but it's also important to take these things in stride (and open issues if you are the first to discover).

I appreciate how well your article is written and enjoyed following your investigation!

Collapse
gaelferrand profile image
GaelFerrand Author • Edited

Thanks for the kind words, and of course, there's a bit of click-baiting here, you're a 100% right, Material-UI is by no means a dead-end. That said, I think it's important to keep in mind that behind its very practical and polished components-library, it has performances issues. Some teams might consider it too big of an issue to go with it!

Collapse
gmartigny profile image
Guillaume Martigny

It would be very interesting to dive in the "Why". What is the cause of this performance loss ? Is it due to <Box> only ? Can you avoid it somehow ? etc

Collapse
gaelferrand profile image
GaelFerrand Author

I agree 100%! But I wanted to keep this article short (and didn't quite succeed did I?). Material for another article I guess ?

Collapse
manuthecoder profile image
ManuTheCoder

Yes,
I agree with you...
Have you tried Vuetify?

Collapse
zhnedyalkow profile image
Zhitomir Oreshenski

This comment is irrelevant with this post. Thanks

Collapse
talorlanczyk profile image
TalOrlanczyk

As far as i know vuetify is for Vue only

Collapse
gaelferrand profile image
GaelFerrand Author

Does it work with React ?

Collapse
miketalbot profile image
Mike Talbot

I had a similar problem with Box etc, mostly based on the fact that the way MUI uses JSS causes vast numbers of things to be added as styles, constantly... In fact in my app "insertBefore" for a style was taking 60% of the rendering time, and goodness knows how much the rest was doing. I found a reasonably easy fix by replacing box with my own version and changing makeStyles from MUI to my own version that caches better. Performance is massively improved.

Collapse
chadalen profile image
Chad Alen

I don’t use it because I don’t want my site to look like google. Also not a fan of material design.

Collapse
jwp profile image
John Peters

Material UI does have a github site and they promise to watch all issue submissions. Please create an issue.

Collapse
gaelferrand profile image
GaelFerrand Author

Performance issues have been submitted before (I put the link of a PR in the article). They're working on it and hopefully sometime soon the lib will be solid

Collapse
eddielewis_92 profile image
Eddie Le

Great post @gaelferrand ! I wish I read this earlier so that I wouldn't feel like banging my head on the wall. Thanks to React MUI, I surprised myself finding out my to-be-upgraded portfolio site performance score (lighthouse) were 46% and 6% on desktop and mobile respectively.

Frankly, I just have no idea where to start fixing after spending lots of time with MUI. Maybe I should be seriously thinking about rewriting all those styles using good old SCSS(?!)🤔