Material-ui: import cost is too much

[saostad]

I am using extension 'import-cost' in VSCode and it shows me import cost below:

import Button from 'material-ui/Button'; is 36.3K gzipped
VS
import Button2 from 'muicss/lib/react/button'; is 4K gzipped

I just simply compare these 2 UI framework and result is just a button!
Why size of material-ui is 9x of muicss?

"material-ui": "^1.0.0-beta.22",
"muicss": "^0.9.30",

[oliviertassinari]

@saostad What about the CSS payload size?

[saostad]

how can i measure it ?

[oliviertassinari]

+6 kB with https://cdn.muicss.com/mui-0.9.30/css/mui.min.css.
Yeap, so we definitely have a higher initial entry price 🤔 .
20 kB gzip comes from JSS, cc @kof. I have tried to reduce the footprint as much as possible.
But I think that we need to do better.
Hopefully, it doesn't hurt the performance that much:

• https://www.webpagetest.org/result/171204_2F_1e85b535bba71bbfcfea012404c29c54/
• https://www.webpagetest.org/result/171204_EJ_df3d8288e94b91966c42d73a4511c9e5/

[mbrookes]

20 kB gzip comes from JSS,

A one-time cost though, right? Unless you only use one Button and no other components.

Partly it's also a tradeoff for having a combined flat, raised and FAB in one component.

[oliviertassinari]

For comparison, Bootstrap CSS is 23 kB gzipped

[kof]

I can reduce the size of the core a a bit by moving internal plugins to separate repos (function values and observables).But this will save probably 1kb at the end. The core itself is about 6kb right now. https://bundlephobia.com/[email protected]

[kof]

The biggest issue with the reduction of plugins is compatibility. I think that we can do it, but we need to remove public api for generic styling. User should use whatever he/she wants, for e.g. directly react-jss. Internal styling should stay internal, that gives you power to optimize without running into issues.

[stunaz]

Just noticed that material-ui depends on lodash. Wouldn't be better to depends on lodash-es to take benefits of tree-shaking?

[mbrookes]

@stunaz We're using:

import debounce from 'lodash/debounce';

So there's nothing to shake.

[TheHolyWaffle]

That's an interesting plugin. Here are some other pretty high numbers that I've found:

[oliviertassinari]

If anyone want to dig into the issue, he can run:

yarn build && yarn size:overhead:why

[oliviertassinari]

I have found an interesting leverage to improve the story here:

• Removing flow Props from the /src
• Migrating the class components to functions. Transpiling a single class introduce 1.8 kB non gzipped.
• Using explicit propTypes over generated one. The current propTypes generation situation is pretty bad (I don't know when the regression was introduced, but it was working with beta.16). They are no linked (no runtime checks 😱 ) nor removed from the production code (dead code 🐳, I think it never worked with flow).

[oliviertassinari]

I'm closing the issue as we have made some progress since it was opened (-7% #9453).
We will keep an important focus on this subject as I think it can be a real blocker for the library adoptions. Many people start using the lib as they need one or two components, a switch for instance. The lower the overhead is for them, the better. The Button component is quite a complex one. I hope that the upcoming Button implementation revamps for matching the specification will allow us to make it smaller :). Thanks everybody for the feedback! If you see a new potential for improvement, let us know.