DEV Community

Cover image for Why you should NOT use Material-UI
GaelFerrand
GaelFerrand

Posted on

Why you should NOT use Material-UI

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!

Top comments (28)

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

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
 
mengboi profile image
MengBoi

It's quite short and precise. I love it.

Collapse
 
eddie_tl 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(?!)🤔

Collapse
 
bilalmohib profile image
Muhammad Bilal Mohib-ul-Nabi

Brother use tailwind css you will be amazed by performance

Collapse
 
kasir-barati profile image
Mohammad Jawad (Kasir) Barati

But what about reinventing the wheel again and again for each project? Do not wanna spend too much time on this things that does not make too much difference when thinking about them in terms of business value and delivering something to the end user. It is just taking too much time to write, test, and let's not forget to maintain.

Thread Thread
 
bilalmohib profile image
Muhammad Bilal Mohib-ul-Nabi

The way to use is such that whenever you need a component specific to a thing which is used very frequently such that a Accordion or something like that then only use that component from mui otherwise use only tailwind css. Thats it.

Collapse
 
antialias profile image
Thomas Hallock

I'm disappointed that your investigation stops as soon as you remove the MUI components, and that without any further investigation, you decide that MUI is just a bad library and should be avoided by everyone.

Did you put any effort into figuring out why the component was killing rendering performance? I'm guessing you had some variable that was affecting the JSS object, which in turn was causing the dynamic stylesheets to be updated on every scroll event. Just a guess.

Collapse
 
bilalmohib profile image
Muhammad Bilal Mohib-ul-Nabi

What I do is nowadays i dont use mui at every component. Using every component of mui would make application too slow its 100% right so instead i try to avoid to use mui as much as i can instead i use tailwind css as much as i can and only use mui special stylish components like textbox or sidebar or buttons which has ripple effect instead I dont use mui. I prefer tailwind css more.

Collapse
 
isggwp profile image
Indra Susila

everybody know mui has

  • lack of documentation about custom styles components,
  • lack performance improvement
Collapse
 
gaelferrand profile image
GaelFerrand • 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
 
joedotnot profile image
joedotnot

It is a dead-end for me, in the same way, Angular is a dead-end for me.. I made the conscious decision to ignore anything that says "material-UI" or "Angular" and focus my time wisely on other things; Using MUI is like learning a new language of "tags". I am happy with plain Html / jsx and CSS. (or another simpler framework like plain bootstrap)

Collapse
 
kasir-barati profile image
Mohammad Jawad (Kasir) Barati

Hmm, I am onboard with bootstrap but do not think we can leverage Bootstrap to develop and ship features and business values as fast as MUI with a fairly good enough acceptable UI/UX. Can we? Just looking for an answer about what others do if they do not use MUI.

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
 
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

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
 
ramirezsandin profile image
Jorge

I'll start considering other options for future projects. More than 42 simple items in a list and you'll start noticing the performance issues.

If you are thinking about using infinite scroll with MUI forget about that, it's going to be horrible performance and supper laggy.

I've even tried to use some virtualization options, but they are laggy per se if the items have a little bit of more than 2 nodes in the inner layout.

Really unhappy with this 😪

Collapse
 
bilalmohib profile image
Muhammad Bilal Mohib-ul-Nabi

What I do is nowadays i dont use mui at every component. Using every component of mui would make application too slow its 100% right so instead i try to avoid to use mui as much as i can instead i use tailwind css as much as i can and only use mui special stylish components like textbox or sidebar or buttons which has ripple effect instead I dont use mui. I prefer tailwind css more.