4 ms·

If the people who came up with this design can not make the demo site performant, site which will be the first impression of your new design language for most,

If the people who came up with this design can not make the demo site performant, site which will be the first impression of your new design language for most, I don't think there is much hope for the rest of us. But since this has name of Google attached to it, many people will mindless ape it to the detriment of experience of their users.

Octoth0rpe 1y ago
I think the people who implement google's html/js/css for random articles aren't particularly connected to engineers working on android/flutter widget performance, and the MUI developers aren't even google employees (mui/flutter being the main implementations of MD AIUI). I'm not at all concerned.
- PaulHoule 1y ago
  Before I got an iOS phone I thought "why do people care about apps?" I mean, there is an app to get me into my gym but with my Android device it would take about 45 seconds to open so I might as well just give them my phone number. It was always faster to go to a web site or go to the public library or do anything other than wait for an app to open.
- WorldMaker 1y ago
  Every Material UI library I've seen in existence is a bloated wreck full of bugs. The Angular MUI "flagship" has the worst performance I've ever seen of basic things browsers have supported for decades and CSS does very well for like buttons. Some MUI teams find ways to bring all of Angular's bloat to everywhere else, the React library is awful. I've had to use MudBlazor, the attempt to do MUI things in Blazor, and it is truly awful. Maybe Flutter is an exception, congratulations to Flutter I guess. This wouldn't be so much of a problem if so many corporations also hadn't somehow decided that MUI was the next Bootstrap and have been treating it as an underlayer in their Design Systems, most of which aren't actually supposed to look like Material and don't really benefit from being huge additional libraries of CSS and components on top of MUI. I blame Figma for this. I don't know that it is any one specific thing Figma is intentionally doing, but the more design teams use Figma the more they seem to think they "need" a safety blanket of Material UI somewhere in the design stack that they won't actually use correctly or well. As an engineer often tasked with performance work, I hate how much of Material UI's braindead approach to performance reflects on me in ways I can't do anything about "because that is the design system you wanted" (not the design system you needed). I wish Material UI would either get significantly better or just die already.
  - Octoth0rpe 1y ago
    I tend to agree with your criticisms. FWIW, I do think mui has peaked, at least for greenfield projects. A new wave of tailwind-based libraries are rising fast, the most prominent of which are Mantine and Shadcn. IME, both perform MUCH MUCH better than mui.
    - WorldMaker 1y ago
      You like the Tailwind-based approaches? That's not the direction I would go either. I've never seen anything Tailwind-based not feel bloated. It's such interesting malicious compliance with "no inline-styles" lint rules by just moving the inline styles into the class field. I see the same problems, including variations on the same performance problems, I remember from the bad old jQuery days of everyone just smashing inline styles everywhere all the time that lead to the "no inline-styles" lint rules in the first place. But I'm a fan of the cascade done right and with CSS Grid and CSS Variables and @layer vanilla CSS cascade is at an all time jam right now. I'd be surprised we aren't seeing more "Design Systems" in that space, but I've got a feeling given how much you can cut from a Bootstrap or Bulma today for CSS Grid/CSS Variables that maybe we aren't seeing a lot happening there simply because not a lot needs to happen there. People happy with the cascade are getting closer and closer to also being happier with "no frameworks" again. Vanilla CSS feels good to work in again.
      - Octoth0rpe 1y ago
        > You like the Tailwind-based approaches? There's two ways of answering this, but both amount to a yes 1) I certainly think much more highly of the recent plethora of tailwind based component libraries than the previous generation, which mostly don't require me to actually use tailwind directly (mantine, daisy). Component library developers seem to like it _a lot_, and the outcome is great. If they're happy to use tailwind and I'm happy with the library that is built on top of tailwind, then I'm happy with tailwind. 2) The other way of answering this is if I'm using tailwind directly. To this point, yes, I'm still happy. The metaphor I've used is that tailwind is to css is as ASM is to machine code. It's still low level, but far, far more ergonomic. And in the end, you often end up using a higher level of abstraction anyway (again, see Daisy, mantine). >Vanilla CSS feels good to work in again. FWIW, I really do agree with this. But I think tailwind + postcss is even better still.
esrauch 1y ago
This page is a promo page of the ux design language people as created by UXD/UXE role people. It's basically like looking at a Figma export and complaining about the performance of it; any actual implementation would be done for any user-facing products realistically will be entirely unrelated both technologically and organizationally.

Octoth0rpe 1y ago

I think the people who implement google's html/js/css for random articles aren't particularly connected to engineers working on android/flutter widget performance, and the MUI developers aren't even google employees (mui/flutter being the main implementations of MD AIUI). I'm not at all concerned.

PaulHoule 1y ago
Before I got an iOS phone I thought "why do people care about apps?" I mean, there is an app to get me into my gym but with my Android device it would take about 45 seconds to open so I might as well just give them my phone number. It was always faster to go to a web site or go to the public library or do anything other than wait for an app to open.
WorldMaker 1y ago
Every Material UI library I've seen in existence is a bloated wreck full of bugs. The Angular MUI "flagship" has the worst performance I've ever seen of basic things browsers have supported for decades and CSS does very well for like buttons. Some MUI teams find ways to bring all of Angular's bloat to everywhere else, the React library is awful. I've had to use MudBlazor, the attempt to do MUI things in Blazor, and it is truly awful. Maybe Flutter is an exception, congratulations to Flutter I guess. This wouldn't be so much of a problem if so many corporations also hadn't somehow decided that MUI was the next Bootstrap and have been treating it as an underlayer in their Design Systems, most of which aren't actually supposed to look like Material and don't really benefit from being huge additional libraries of CSS and components on top of MUI. I blame Figma for this. I don't know that it is any one specific thing Figma is intentionally doing, but the more design teams use Figma the more they seem to think they "need" a safety blanket of Material UI somewhere in the design stack that they won't actually use correctly or well. As an engineer often tasked with performance work, I hate how much of Material UI's braindead approach to performance reflects on me in ways I can't do anything about "because that is the design system you wanted" (not the design system you needed). I wish Material UI would either get significantly better or just die already.
- Octoth0rpe 1y ago
  I tend to agree with your criticisms. FWIW, I do think mui has peaked, at least for greenfield projects. A new wave of tailwind-based libraries are rising fast, the most prominent of which are Mantine and Shadcn. IME, both perform MUCH MUCH better than mui.
  - WorldMaker 1y ago
    You like the Tailwind-based approaches? That's not the direction I would go either. I've never seen anything Tailwind-based not feel bloated. It's such interesting malicious compliance with "no inline-styles" lint rules by just moving the inline styles into the class field. I see the same problems, including variations on the same performance problems, I remember from the bad old jQuery days of everyone just smashing inline styles everywhere all the time that lead to the "no inline-styles" lint rules in the first place. But I'm a fan of the cascade done right and with CSS Grid and CSS Variables and @layer vanilla CSS cascade is at an all time jam right now. I'd be surprised we aren't seeing more "Design Systems" in that space, but I've got a feeling given how much you can cut from a Bootstrap or Bulma today for CSS Grid/CSS Variables that maybe we aren't seeing a lot happening there simply because not a lot needs to happen there. People happy with the cascade are getting closer and closer to also being happier with "no frameworks" again. Vanilla CSS feels good to work in again.
    - Octoth0rpe 1y ago
      > You like the Tailwind-based approaches? There's two ways of answering this, but both amount to a yes 1) I certainly think much more highly of the recent plethora of tailwind based component libraries than the previous generation, which mostly don't require me to actually use tailwind directly (mantine, daisy). Component library developers seem to like it _a lot_, and the outcome is great. If they're happy to use tailwind and I'm happy with the library that is built on top of tailwind, then I'm happy with tailwind. 2) The other way of answering this is if I'm using tailwind directly. To this point, yes, I'm still happy. The metaphor I've used is that tailwind is to css is as ASM is to machine code. It's still low level, but far, far more ergonomic. And in the end, you often end up using a higher level of abstraction anyway (again, see Daisy, mantine). >Vanilla CSS feels good to work in again. FWIW, I really do agree with this. But I think tailwind + postcss is even better still.

esrauch 1y ago

This page is a promo page of the ux design language people as created by UXD/UXE role people. It's basically like looking at a Figma export and complaining about the performance of it; any actual implementation would be done for any user-facing products realistically will be entirely unrelated both technologically and organizationally.