Material Design Components Web is as incomplete and as slow in progress as Material Design Lite

[jimbojetlag]

Please find below my comments and questions about the MDC Web. These did not feel right to be published on Stackoverflow, as SO comes with the high risk of mods flagging questions like this. I am writing this as after a long research on which MD implementation to use for our user facing web app, our team ended up being frustrated with the approach of Google about making many projects that seem to have the same functionality, only to kill some of them in the future.

1. MDC Web tries to be framework agnostic, just like MDL. Yes there are advantages when doing this, but they come with this major major drawback: Developing new components is difficult, time consuming and error prone. There is no easy way of state managements, no templating, all the advances in virtual DOM are ignored. In our opinion, this is exactly what killed MDL and I do not see why it shouldn't kill MDC Web too.

2. MDC Web was published back in December 2016. It is a paid project, backed by Google, and a dedicated team. Yet after over a year, the implemented components are really incomplete comparing to many MD implementation out in the wild by single unpaid developers. I refer you to point 1 for one of the reasons behind MDC Web progress being slow.

3. What is the target product for MDC Web? Is it web applications, or websites? If it's for websites, then MDC Web is just a rewrite of MDL. If it's for web applications, how are we web app developers supposed to use MDC Web for non trivial apps? I can see some authors of the project recommend using MDC Web in parallel with other frameworks. Every major framework out there now comes with a mature MD implementation and override MDC Web components. Why would we use an MD library in React, and then opt to, say, use text field component of MDC?

4. Which Google products use MDC Web? One of the major drivers of making progress with the components is when the library is used in real world products.

[robcaldecott]

IMHO I think one of the issues is that the new MD spec itself is still in flux so they have to keep updating this lib accordingly.

I doubt anyone from the team will comment but it would be great to have some idea of an ETA for a beta release and an end to breaking changes.

We're using MDC heavily with React and I agree about the framework agnostic model sometimes being a double-edged sword. In some cases we have opted to replace the MDC JS with pure React code to address issues and to make upgrades a little easier. For some components it's little more than adding/removing styles or simple event handling which is easy to replace and enhance. Other components are more problematic because there is a ton of code behind them (drawers and sliders are the big ones.) CSS ripples are also fine for example, making button and switch components simple to implement in React, plus we get to choose which classes to implement based on our own UX guidelines (so we have limited component props in some cases.)

MDC is very careful to never add or remove elements from the DOM, so it does fit well with multiple modern frameworks and libs, but I personally prefer reactive code over imperative. But YMMV.

I also feel that this team does a fantastic job of doing as much with CSS as possible which makes implementing pure React components so much easier. Long may this continue (I tried to implement an input "range" slider component and the differences between browsers explains why the MDC slider component is basically a custom JS component.)

We also filled in some of the gaps ourselves or opted for other 3rd party components that could be themed to look like MDC (the Airbnb date picker, ag-grid) but it isn't perfect. Eventually I'd like to share some of our additions but not while the core CSS is still in alpha.

Overall our experience with MDC has been excellent though: all that official scss alone, which is dead simple to theme, has given our web apps a modern look and feel and has saved us from spending time and money implementing our own company design language. But we would love to see some stability, an official beta release and long term support from Google. We went with MDC because it's the only official Google MD implementation...

[jimbojetlag]

IMHO I think one of the issues is that the new MD spec itself is still in flux so they have to keep updating this lib accordingly.

I would disagree. It's not about 'updating', the components do not exist in the first place, let alone updating them.

Let me make this clear with a discrete example. Autocomplete component is given in MD specs, and is heavily used in most modern web apps. Here is an implementation of MD autocomplete, scroll down to see the complex examples. Let's track what the team has done about this component:

• There is an issue for autocomplete in MDL from mid 2016 which was never implemented.
• The same issue was migrated to MDC by the end of 2016, with no activities.
• Here is the same issue in their pivotaltracker, tagged as tricky-feature. The fact that they tag some component implementation as "tricky" says that something might not be right about their decision of sticking with vanilla javascript. Building a nontrivial autocomplete component with vanilla js is indeed tricky. Just look at the source code of jQuery select2 or React typeahead, or Google's own Closure Library autocomplete, and you will see that it will have a lot of work, and bugs, in vanilla js. I have a feeling that some time in 2020s, when MDC is abandoned, the autocomplete components is still not implemented.

I doubt anyone from the team will comment but it would be great to have some idea of an ETA for a beta release and an end to breaking changes.

I do not see why the team should not respond to this, we see what described in this issue as valid points. As with an ETA, if you see MDL github issues and their gitter channel, their default response to the ever missing components always was "it is done when it is done". Since this is a "Google first" project, components that are not dependencies in Google, are not of priority.

[jimbojetlag]

I just saw #2399 where they downgraded select menu component to native, because of "low bandwidth". Perhaps we should not expect an autocomplete component when the team's lack of resources literally downgrades components to native browser elements.

[lynnmercier]

MDC Web will continue to be framework agnostic with our Foundation/Adapter pattern. This pattern allows us to push Material Design changes to wrapper libraries quickly.

Other libraries that Do Not depend on MDC Web have reverse engineered MD by looking at spec or our catalog. When MD changes, these libraries may not update their implementations. The more MD changes, the farther behind these other libraries become. In the end, all other libraries, that Do Not depend on MDC Web, have a different interpretation of what Material Design truly is.

We have not been focusing on building shallow implementations of all MD components. Instead we've focused on building a robust implementation of a few MD components. We've found that getting just one component to work in multiple situations (multiple Web platforms, multiple browsers, RTL, accessibility, color customization, typography customization) is ... well ... tricky!

But I am confident our level of attention on this smaller set of components will make MDC Web a long running and maintained product.

We have had difficulties managing our breaking changes. We want to move quickly (we have to keep up with our wonderful Material designers!) but when too many APIs change too quickly it is hard for our customers to rely on our components. We hear that, and we're taking actions to slow down the rate of breaking changes. We hope to have more announcements about that soon.

But breaking changes will not come to some final end, because design is never done, so MDC Web is never done.

And @jimbojetlag you're welcome to implement your own autocomplete that matches Material Design. We'd love to hear about your experience with browser compatibility, RTL, accessibility, etc.

[jimbojetlag]

Thank you for your response @lynnjepsen. While I hear your reasons behind the strategy for MDC Web being used as a core library, providing adapters for popular frameworks, I do not see this approach to be sustainable for the following reasons:

1. You made it clear in Decide the future of our framework examples #983 that Google does not have enough resources to get experts working on MDC Web framework adapters, and hence, it is left to the open source community. This means backlog of new features and bug fixes, in addition to more risks explain in point 2.
2. Javascript libraries have a much shorter life than domestic pets. These days relying on a single Javascript library needs careful research to minimize the risk of the dependency discontinuity. Your strategy requires your users to rely on 2 libraries (MDC Web and a community maintained adapter). If on average there is a 50% chance that a Javascript library is deprecated in 2 years, that chance is increased to 75% when using MDC Web through a community maintained adapter.

And @jimbojetlag you're welcome to implement your own autocomplete that matches Material Design.

You have already provided my response to above:

Other libraries that Do Not depend on MDC Web have reverse engineered MD by looking at spec or our catalog. When MD changes, these libraries may not update their implementations. The more MD changes, the farther behind these other libraries become. In the end, all other libraries, that Do Not depend on MDC Web, have a different interpretation of what Material Design truly is.

For all the excellent reasons you enumerated, we should not try to implement our home grown MD autocomplete (an an example of one of many) component.

[kmmbvnr]

@lynnjepsen could I suggest to concentrate on CSS-only components first? Having building blocks and stable CSS class names for wild range components would greatly improve MDC usage experience.

Ex, you don't have to build autocomplete component completely, just CSS and demo statically shows common states would be useful.

[bbarnell]

@lynnjepsen Could you please answer question number 4 from the original post:
Which Google products will use MDC Web? One of the major drivers of making progress with the components is when the library is used in real world products.
If the community knew that G Suite was planning to use MDC Web, it would be a huge boost to confidence in long term support for this library.

[dandv]

If strict adherence to MD is not critical, there are alternative Material Design implementations that offer far more (and more powerful) controls, like sortable and filterable tables, or even trees. One of these libraries, Webix, has some ~65 widgets at 234kb gzipped in its OSS offering, and that includes autocompletes as just one of the numerous input controls. There's a Material Design skin and a skin builder as well. It targets admin interfaces on desktops, but works well on mobile too.

[bbarnell]

@lynnjepsen
Any chance you could update the "Milestones" information on GitHub? They have not been updated in 7 months. Also, maybe remove the "Theme Improvements" milestone since it has been done for a long while.

[Splaktar]

I just wanted to mention that it seems like the Milestones have been updated more frequently now and seem to be accurate. 👍

[asyncLiz]

I'm going to go ahead and close this seeing as a lot has changed about the project over the past year. Feel free to open a new issue if you have any suggestions on current components or recommendations for those not yet implemented.