-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Material Design Components Web is as incomplete and as slow in progress as Material Design Lite #2639
Comments
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... |
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:
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. |
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. |
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. |
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:
You have already provided my response to above:
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. |
@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. |
@lynnjepsen Could you please answer question number 4 from the original post: |
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. |
@lynnjepsen |
I just wanted to mention that it seems like the Milestones have been updated more frequently now and seem to be accurate. 👍 |
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. |
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.
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.
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.
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?
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.
The text was updated successfully, but these errors were encountered: