@oliviertassinari Thanks so much for taking the time to look into this, and do research around potential pros and cons of integrating MDC-Web with Material-UI. Many of us on the team have used (and enjoyed using) Material-UI for React projects we've worked on in the past, and are extremely excited at the thought of integration between our two libraries. Obviously I'm a bit biased here but here are my thoughts on what you've written above.

Alignment with Material Design

You're absolutely right in that by using MDC-Web, you get a faithful and accurate representation of Material Design as it is envisioned on the web platform by Google's Material Design team. Some things that you may see may be different from exactly what's in spec. This is known by the designers, because we have worked with them to determine that what we have works best for the web platform. For example, we originally used textarea elements instead of "multi-line text fields", because we as web developers knew that this is what users looking for a "multi-line text field" would expect on the web. Rather than hack together a "single line text field that grows", we ran this by design and they agreed that this was a more appropriate pattern. You can now see textareas being represented in our latest text fields spec.

Time Saved writing CSS (and JS)

In terms of writing CSS, it should be extremely minimal, if not at all necessary. Material Design is extremely tricky to get right from a purely visual perspective. Add in RTL, accessibility, and customization (all which we fully support) and it becomes a full-time job just implementing the correct stylistic solution for these components, let alone maintaining idiomatic react bindings for them. Our goal with making MDC-Web have first-class support for framework integration by design is to allow framework library authors to simply focus on making their MD components idiomatic for their framework, while letting us sweat the stylistic details. As a matter of fact, React is usually our litmus test for new components to test how well they'll integrate, due to its popularity and usage on the web platform.

External Contribution and Google Adoption

We indeed have developers from all different frameworks background contributing to MDC-Web, and we are actively working to increase adoption of the library across a multitude of Google products.

The "vision" for Material-UI

"My vision of Material-UI is to be much more than a Material Design implementation for React."

This is an interesting viewpoint. I will honestly say right off the bat the the only goal of MDC-Web is to be a Material Design implementation for the web platform. Nothing more, nothing less. We do hard-code some constraints regarding dimensions, etc. into our styles based on those design guidelines which are not meant to be changed. We would not consider making changes to our components - especially UX changes - that would facilitate additional flexibility at the cost of breaking with the core Material Design system, as that is a non-goal of our project.

Customization

That being said, in terms of "customization" re "business custom style", that is something we absolutely support. Our theming system allows you to use any combination of styles and colors. Our typography system is largely opt-in, and should work with most font-faces optimized for latin text.

Even if you need to add your own custom styles via CSS overrides, it shouldn't be an issue. Our DOM structure for every component is versioned. If the DOM structure changes such that it would cause a stylistic breaking change, we consider it a major version bump. Therefore, you will never run into issues where, say, a transparent version update to MDC-Web causes a major visual regression in Material-UI due to custom styles being added to a DOM component. Furthermore, we do have governance around UX changes that are proposed by the community.

In terms of JS API customization, our adapters were designed from the ground up for maximum flexibility. In our react example, you can see that all DOM interactions (adding classes, setting attributes, etc.) are proxied through the adapter, giving you complete control over when and how those changes take place. Furthermore, support for non-web platforms like React Native could in theory be supported using tools like react-native-css.

"First-Class", Destiny Control, etc.

It really comes down to this: what is the goal of Material-UI?

Is the goal to be a library that allows developers to implement Material Design in their React apps? If so, then I believe that MDC-Web is a perfect fit.

Is the goal to be a general-purpose UI library that allows the use of Material Design elements but is not specific for that design system? In that case, using certain aspects of MDC-Web may be appropriate but it's probably best not to bet the farm on it.

This goal setting is something I feel that all teams - including MDC-Web - must reflect on as it informs pretty much every design decision around a library. For example, React's as far as I can remember has always been the same - A JavaScript library for building user interfaces. This focused goal of doing one thing and one thing really well is what IMO has allowed React to succeed and thrive in the way it has, while being able to move quickly, adapt to change, and build up an ecosystem of supplemental tools and libraries to support broader use.

Project Maturity

This is an area where you can help us! We'd love to work alongside you as you develop your next branch to ensure that we are indeed building our library in a way that can be leveraged by the entire web dev community, a large part of which is the React community. If that's not currently the case, then we need to take a step back and figure out what's preventing that from happening.

A final thought: Use only what you need at first, and evaluate from there.

MDC-Web - unlike MDL - is 100% modular. There are lots of things in MDC-Web that are encapsulated within their own modules that you'd most likely have to re-implement to the letter yourself within your library, such as elevation, typography, animation primitives, and the (in)famous ink ripple. These can all be used independently of one another. Why not try out some of the more simplistic libraries, like @material/elevation, and then evaluate and build up from there? At best, it's a great way to get started feeling out what an integration would look like without betting the farm on the library or spending too much time on a complex component. At worst, you now have shadows solved for your library 😄

Thanks again for this research and let me know how things go! Feel free to reach out to us on our discord channel if you'd like to discuss this further.

Modular use

MDC-Web - unlike MDL - is 100% modular. There are lots of things in MDC-Web that are encapsulated within their own modules that you'd most likely have to re-implement to the letter yourself within your library, such as elevation, typography, animation primitives, and the (in)famous ink ripple. These can all be used independently of one another. Why not try out some of the more simplistic libraries, like @material/elevation, and then evaluate and build up from there?

This is an interesting idea for:

1. 1st implementation of a component that we have not proven any need to go further; or
2. An internal component that we do not allow for customization

assuming:

1. it doesn't overly complicate something like a tool-chain (I don't think it will)
2. we remain in control of our own destiny

A word on control of our own destiny:

If we started using a component from MCW in this manner, we need some rational constraints on what we allow to be done in code. My concern is that incrementalism will lead to little hacks over top of MCW, instead of doing the harder rewrite to match our customizable components. In our favor, we have a great PR review process in-place already, so I think it's feasible to consider.

Vision/Goal

My vision of material-ui is to become whatever is generally useful for application development in the spirit of the Material Design spec. This means Material Design with a general use UI library of components that are needed by many. This general use doesn't imply any other design methodology. It also means we will have components or combinations that are simply not addressed in the spec.

Divergence

With this vision/goal, this might mean that we have a greater impetus to change few components' UI/UX in very small ways that could be very important to a business application, but rejected by a design team (and MCW). I have great respect and appreciation for what the google design team has done; my concern is being painted into a corner. In my experience, this corner-painted scenario usually ends up in the 11th hour of project delivery, and I would hate to endure a rewrite late in the game.

So, we have to discuss divergence. If we invested and had a reasonable conflict understanding both projects' goals, what does working together with some divergence look like? A maintained fork that is kept up-to-date with the upstream? Custom SCSS added without a fork? No divergence allowed - require a rewrite with our current stack?

Final words - personal opinion

Outside my membership with the project, I want to add my opinion as a user of material-ui.
next is currently a pleasure to work with. It delivers on fully encapsulated react components. Whatever happens, I don't want less developer joy.

@traviskaufman

by using MDC-Web, you get a faithful and accurate representation of Material Design as it is envisioned on the web platform by Google's Material Design team

There's no easy way to say this without coming across arrogant and superior, but I'll take that on the chin on the basis that what I'm about to say is not my doing, but thanks to the work of our amazing community: from what I've seen, MDC-Web has a looong way to go before it can come close to Material-UI in that regard. (Granted, your Waterfall Toolbar is pretty sweet!)

We have poured over the spec, debated the gaps and inconsistencies, and tried and experimented with CSS and JS to achieve the ideal representation, while retaining the flexibility for users to customise to their need. There are many man hours of lessons learned baked into the published version, and carried over and improved on in next, both from a technical and a design standpoint.

Right now, I can see little that MDC-Web offers that will move this project forward in any meaningful way.

@rosskevin

1st implementation of a component that we have not proven any need to go further;

Maybe in the future. As it stands, MDC-Web has less components implemented than the next branch, let alone what's on master.

My vote is to carry on as we are, with a watchful eye on MDC-Web as it matures. We might learn or even borrow from it, but any integration is a distant future (if ever), not something we should worry ourselves with now.

Why not try out some of the more simplistic libraries, like @material/elevation, and then evaluate and build up from there?

@traviskaufman That's an excellent suggestion. We hit the hard part: the style architecture. While material-components-web uses SASS to write and deliver the styles Material UI uses JSS. This is a fundamental different.
As far as I see this direction, that's the biggest problem we need to address if we want to move forward from a technical point of view.

I have found an interesting project to potentially solve that point. Prejss made by @DenisIzmaylov allows to get JSS objects "on-the-fly" from plain CSS, PostCSS, SCSS, CSS Modules, Stylus and LESS styles. Some of the criteria I can think of that we need to check:

• Build size implication
• Performance implication
• Theme and customization implication
• Automatic documentation generation implication
• Test implication

Also, I'm gonna try to summarise the vision of the project in a VISION.md. @mbrookes This time, I'm gonna let people time to review it 😁 .

I'm going to close this issue for now. We can take another look at this discussion if we encounter the need.

So, I noticed Material Design updated their website and I noticed there is a library which wraps the material-components-web in React. Should we re-open this issue for discussion?
https://github.com/jamesmfriedman/rmwc

There is also a mysterious repo material-components/material-components-web-react which has been quite active lately but I haven't seen any official announcement from Google yet

@AnaRobynn Right now, I believe different tradeoffs and competition can help move the community forward. I'm not sure we should change the approach.

I've been playing with material-components-web + react wrappers, all of them are buggy as hell. I've been having a love-hate relationship with Material UI, but I stick to Material UI because of the stability.

That being said, I would feel more comfortable riding on a "web" UI framework with multiple VDOM library-support not just a "react" UI framework, knowing that the UI part will always evolve independently of which JS framework is trending. However I have yet to find one solution that is has polished as this one.

BTW: Material Components for React (MDC React) (https://github.com/material-components/material-components-web-react) are no longer under active development.

@JacekKosciesza The last time I talk with the Material Design team, they told me that they were stopping/pausing this effort. They have never invested a lot of resources in the React wrapper yet. I think that it was great for them to explore the potential of the wrapps around Web components. Vuetify, Material-UI, and Angular Material model challenges the idea.