Why you should NOT use Material-UI

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…


This content originally appeared on DEV Community and was authored by GaelFerrand

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!


This content originally appeared on DEV Community and was authored by GaelFerrand


Print Share Comment Cite Upload Translate Updates
APA

GaelFerrand | Sciencx (2021-02-16T17:32:17+00:00) Why you should NOT use Material-UI. Retrieved from https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/

MLA
" » Why you should NOT use Material-UI." GaelFerrand | Sciencx - Tuesday February 16, 2021, https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/
HARVARD
GaelFerrand | Sciencx Tuesday February 16, 2021 » Why you should NOT use Material-UI., viewed ,<https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/>
VANCOUVER
GaelFerrand | Sciencx - » Why you should NOT use Material-UI. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/
CHICAGO
" » Why you should NOT use Material-UI." GaelFerrand | Sciencx - Accessed . https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/
IEEE
" » Why you should NOT use Material-UI." GaelFerrand | Sciencx [Online]. Available: https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/. [Accessed: ]
rf:citation
» Why you should NOT use Material-UI | GaelFerrand | Sciencx | https://www.scien.cx/2021/02/16/why-you-should-not-use-material-ui/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.