[TreeView] The node takes time to open

[Rajaa-BARHTAOUI]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

• We need to display a tree that contains many nodes, but it takes time to open the node.
• We think this is related to the performance of the machine because we have done a lot of testing.
  So, we get
  • Same rendering on Chrome and Fiferox
  • The rendering is better on more powerful machines

Expected Behavior 🤔

• No lag when using TreeView with over 200 nodes to display

Steps to Reproduce 🕹

Test online

Context 🔦

Your Environment 🌎

`npx @material-ui/envinfo`

 
System:
    OS: Linux 5.4 Ubuntu 20.04 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
    Memory: 240.19 MB / 15.36 GB
    Container: Yes
    Shell: 5.0.16 - /bin/bash
  Binaries:
    Node: 14.17.0 - ~/n/bin/node
    Yarn: 1.22.10 - ~/n/bin/yarn
    npm: 6.14.13 - ~/n/bin/npm
  Managers:
    Apt: 2.0.2 - /usr/bin/apt
  Utilities:
    Make: 4.2.1 - /usr/bin/make
    GCC: 9.3.0 - /usr/bin/gcc
    Git: 2.25.1 - /usr/bin/git
    FFmpeg: 4.2.4 - /usr/bin/ffmpeg
  IDEs:
    Nano: 4.8 - /bin/nano
    VSCode: 1.46.1 - /usr/bin/code
    Vim: 8.1 - /usr/bin/vim
  Languages:
    Bash: 5.0.16 - /bin/bash
    Perl: 5.30.0 - /usr/bin/perl
    Python: 2.7.18 - /usr/bin/python
    Python3: 3.8.10 - /usr/bin/python3
  Browsers:
    Chrome: 83.0.4103.106
    Firefox: 89.0.2
  Monorepos:
    Yarn Workspaces: 1.22.10

[eps1lon]

Thanks for the feedback.

There are two independent issues here:

1. performance in development vs production
   React has a lot of dev-only checks that make it slower in development.
   We only work on performance problems that occur in production. I suspect that in production the problem is not as severe.
2. large number of items
   This is tracked in https://github.com/mui-org/material-ui/issues/20951

[oliviertassinari]

I'm going off-topic on this issue. mui/mui-x#9685 is the way to go.

We only work on performance problems that occur in production.

@eps1lon Should we? The faster the dev environment is, the more time developers can improve the UX and the experience for end-users. It's also giving them more confidence that the end result will be of quality.

How about we introduce a threshold for when performance in development matters? For instance, maybe we could say that when dev is x3 slower than in production it matters?

[eps1lon]

@eps1lon Should we?

Yes, everything else is not actionable. When a tradeoff between user and developer has to be made, then we choose the user over the developer. The developer is more likely to be in a position to upgrade their machine.

For instance, maybe we could say that when dev is x3 slower than in production it matters?

This is already unreasonable.

[Rajaa-BARHTAOUI]

@eps1lon Thank you for your answer. We have no lag when we switch to production mode.

Thank you ^_^

[oliviertassinari]

When a tradeoff between user and developer has to be made, then we choose the user over the developer.

@eps1lon I think that we can nuance it to match how the best product decisions could happen and to be compatible with Company ultimate objective. At the end of the day, we are used by developers, not end-users. I assume that developers pick tools they feel help them get the greatest work done. Great work for them means, among other things, great end-user experience. But it's not the only dimension they also look at, e.g. DX. So I don't think that end-users should be the only dimension for us.

Sure, we can decide to have Material-UI have an extra emphasis on end-user, rather than, DX, speed, design quality, but would this yield to doing the most good for end-users? I would challenge it. Does React provide a better end-user UX than jQuery? It's unclear to me. But DX, for sure yes. In the best of the worlds, the great UX and DX come together, like when Next.js appeared in 2017.