Why you should NOT use Material-UI

GaelFerrand — Tue, 16 Feb 2021 17:32:17 +0000

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 :

Each item in the list can be collapsed / uncollapsed :

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

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 :

Giving non-index, unique keys to each item in the list
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 :

We can notice :

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

On the image I highlighted 2 things :

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
What seems to be taking quite some time are the "headers" (on the left).

Just to be clear, this is a "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>

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>

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 :

If your read that right you'd see that :

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

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!