I forgot to add yesterday, I tested with the simple to do tutorial without SSR and I get the same issue, repo is here: GitHub - simplecommerce/mui5-meteor-simple-todo
Also wanted to add, it only seems to do this with MUI v5 since my current project is on v4 and I have no issues with it, so it really is weird.
I don’t know if I should open an issue in Meteor or MUI github?
If you do, please link this as well: [Modal] Marking large trees as aria-hidden causes slowdown in Chrome on Android · Issue #21578 · mui-org/material-ui · GitHub and if not too much trouble, thumb it up as well.
I updated the simple to do repo, I added a test with the Modal component, and that one seems to open quickly on the initial load, so it seems to only affect the Dialog and Menu components, no idea if any others are affected since I haven’t gotten to test them yet.
I opened up an issue on MUI here for reference: Dialog and Menu freeze delay on initial open on MeteorJS platform · Issue #29131 · mui-org/material-ui (github.com)
Are anyone running MUI v5 with Meteor without experiencing drastically slow first renders?
I have an older project with MUI v4 that’s working just fine, but in a new project with v5 everything is slow on the first render, even clicking a button will hang the application for secounds before continuing. After the first initial hang everything starts behaving as normal. The same issue occures everytime I open a modal without using the keepMounted prop wchich I guess is because a new component gets rendered for the first time.
It does not look like other frameworks are experiencing the same issue so I am wondering if someone with a greater knowlage of the Meteor internals might be able to find out why this is happening specifically in Meteor projects.
I am experiencing the same on my end, I opened an issue on MUI’s github, waiting on their findings. Another dev also posted a repo that demonstrated the issue is with all components which I did not notice. I haven’t opened an issue in Meteor’s github yet since its MUI’s package. Hopefully we’ll get answers soon, unless someone here or reading can figure out what the issue is or where it comes from to help speed up getting this fixed.
@kheang @zayco How are you guys importing the component?
There’s a difference when you import an MUI component like this:
import { TextField } from '@mui/material';
Instead of:
import TextField from '@mui/material/TextField';
When you import like in the first example, the whole MUI library will be downloaded to the client instead of just the component on the first load. After that the code stays kind of cached, that’s why the second load is faster.
This is just a hunch but it could be the problem.
In my repo I am using the demo from their documentation which uses the 2nd way you described.
Thanks for the tip. I am using the second type of import
@denyhs comment would make more sense before Meteor 2.4.
If you are using Meteor 2.4 the difference from importing everything shouldn’t be that bad (of course you could avoid it), specially in development.
It seems that you are not sure if this is a Meteor issue or a Material UI issue, right?
Could you use the Performance tab in Chrome Dev Tools to see which modules are being executed when the app is slow, so you would know better if maybe this is Meteor parsing the files or the library itself.
@filipenevola Not sure if this helps but another user has commented on my post on MUI’s github with a screenshot of his profiler tab that shows a delay on initial load: Dialog and Menu freeze delay on initial open on MeteorJS platform · Issue #29131 · mui-org/material-ui · GitHub
I haven’t tested the latest Meteor update yet, but as previously mentioned, we are using the demo with the correct imports directly for MUI’s documentation so that part should be ok.
I am not an expert with performance/profiling, I will try to test it in a bit.
If anyone else is more familiar and can do the test, I welcome it.
Thanks for your reply!
@zodern I believe this would be a nice case for you to investigate.
I did a quick profile here and it seems they (mui) are somehow deferring the evaluating of modules, I didn’t check their code but in the profile I see the runSetters calls running later so I think they are using something to avoid importing all the modules in the first load.
It seems something started by insertStyles function.
I think this is the same issue as Unexpected module.runSetters wrapping · Issue #277 · benjamn/reify · GitHub. In the code there are parameters that have the same name as exports, and where the parameters are reassigned reify is unnecessarily calling runSetters. ~90% of the time is spent by runSetters, and quickly looking through the code I don’t see anywhere that it needs to be run.
would this be Meteor’s code or MUI causing the issue? I could link the issue you posted on my MUI issue post.
The issue is in reify, which Meteor uses as part of its module system.
Thank you for your help!!
We are going to start trying to fix this issue in a few weeks.
Thank you, appreciate it!!
Same issue here. The fix would be a great performance improvements for those using MUI5.
Really looking forward to it.
At this point, you could say that material-ui v5 is not compatible with Meteor 