Material UI v1 for React is out | Hacker News Reader

Material UI v1 for React is out

medium.com

169 pointsdeadcoder090454 comments

This looks like great work, but I must be wired wrong, but I hate material UI usability on the desktop. I found myself to be much more productive with more traditional approaches. I don't mean component look/design which I don't really care, as long as I can identify a button, but more the trend to organize things, well "differently". For example, the play store developer dashboard is a nightmare to use, it takes me forever to find functions X or Y. I don't know, "in the old day" I could find where function X would be located very quickly, now I have to search the UI in all places and expand everything until I can find it. Also actions available only when hovering something with the mouse are sometimes hard to discover, especially for keyboard users like me who "tabs" through all controls in a page.

I'm with you on this. I just don't find Material to be visually appealing.

Material Design is fundamentally broken. It's based on the idea that things should look like animated physical materials, but UIs shouldn't look like real motion, because there are many people out there with visual motion accessibility issues.

Animation should be kept to an absolute minimum unless you're making a game.

>UIs shouldn't look like real motion, because there are many people out there with visual motion accessibility issues.

Could you expand on that point? I'm struggling to think of a user group whose experience would be fundamentally broken by the use of motion in Material. Could you give an example? I use Material extensively and would like to think that I have a good understanding of accessible design, but I'm always looking to improve.

The simplest example I have is text input field with placeholder "transforming" into the label when the field has focus. This simple animation and often color change of the text can be disturbing, especially when the appearance of the keyboard (on mobile) pull the field to the top and hide the label. On desktop, the label can become too small to read when above the text field. This is not really a problem for me, but I've seen people complaining about it.

If I think about complaint I would have, take the dialog spec[1], both "ACCEPT" and "CANCEL" "button" have same color and size, this is terrible design. I am going to do a destructive action, I need more distinction on what I am going to do. It should read "cancel" in a normal button and "reset settings" in a red button.

Looking at that page, I realize another MAJOR annoyance[2], what is "123 main street..." description? special "location" event attribute? Removing label from filled field is so bad for usability, for ALL users.

I could go on forever with what is wrong on every material design page.

[1]: https://material.io/design/components/dialogs.html [2]: https://material.io/design/assets/1K06WW9W94mIiLOEUwXV6Jf7QL...

> If I think about complaint I would have, take the dialog spec[1], both "ACCEPT" and "CANCEL" "button" have same color and size, this is terrible design. I am going to do a destructive action, I need more distinction on what I am going to do. It should read "cancel" in a normal button and "reset settings" in a red button.

This is easily done by setting an md-warn attribute on the cancel button, e.g., https://material.angularjs.org/latest/demo/button

It is up to the designer to scope out the magnitude of destruction the action will cause and select the right color/hue, and even set md-raised on the default action in a workflow.

Well, if your app have an orange/red primary color, the warning color is just ignored.

And again, I am not saying that material design is bad "by design", I am saying it is not always well used, and that I personally don't like it.

> Well, if your app have an orange/red primary color, the warning color is just ignored.

This is incorrect. If you use Material color templates and pick red as the theme, md-warn will pick an alternate accent color.

> And again, I am not saying that material design is bad "by design", I am saying it is not always well used, and that I personally don't like it.

No disagreement there. Some of Google's own apps butcher Material Design. YouTube Music on Android is a usability mess.

I'm building my SaaS front-end on react-semantic ui [0]. (non dev builder here).

Besides population familiarity with material UI because of Google, am I missing something ?

Things I like about React semantic :

- very clean documentation : i can search, find , and tweek components

- Semantic is less opinionated visually than Material (IMO), and do appreciate lightweight.

[0]https://react.semantic-ui.com/

I tried both at the beginning of 2016, and neither of them seemed very usable at that stage. Both look much better now, and I can't wait to give them a shot.

Also noting that the semantic UI docs still give a horrible mobile experience (iOS 11).

I've been using SUIR in production for about a year now. It's been working out pretty well.

Semantic UI is anything but lightweight.

Yeah, it feels more heavy to me as well.

I meant lightweight visually

The main dislike I had of using Material Design was trying to make it not look like just another Material App.

With bootstrap the basic buttons are fairly simple, so distinctive theming was easy, but with all the shadow and shimmer effects of the Material Design components its a lot of work if you want to change their structure to give it some of your own app's personality.

I switched from material design (react-toolbox) to semantic ui around a year or two ago for similar reasons.

Material design looks great by default but it infects the rest of your app really quickly since any custom components you build have to match it in visual style or it'll look really out of place. This was pretty hard for a small project without a designer.

Semantic basically looks like bootstrap without being bootstrap and is much easier to work with.

Semantic UI React is amazing. I've used it to build a number of applications. My favorite thing is the interoperability between its various components.

I looked a bit at this while it was still in beta, and it seemed to be one of the more comprehensive UI libraries for React, and also one of the more active projects. It also isn't restricted to desktop use like some of the other UI libraries.

I'm curious about the choice for styling components, there seems to be a lot of different approaches and no clear winner.

When development of v1 started, JSS was the only solution that (with some tweaking) met all the needs of component library (as opposed to say, an application), as well as being one of the most performant.

The thread that this comment[1] is in is where it all starts, but the repo and presentation linked from that comment should give the answers. At least as a snapshot at that point in time).

[1]https://github.com/mui-org/material-ui/issues/4066#issuecomm...

Awesome news, I have been following the beta for the last year, upgrading versions every couple of weeks. The TypeScript definitions were perfect to catch changes especially in property names. Will get my site upgraded ASAP. Can't wait to see where you take this next.

Congratulations and thank you! This is a fantastic library, my team has been using the beta versions successfully in both desktop and mobile projects. The overall quality of and amount of components in this library has resulted in a major productivity and user experience boost for us.

Congrats! I've played with this on various projects for year now.

The only thing I keep getting frustrated with is styling with Typescript. I don't like the withStyles HoC but the alternatives still feel difficult to use.

I would love to just use a decorator but I believe there's a TypeScript feature still missing in order to support it correctly. I'm curious if the recently announced TS 2.9 changes will help.

Myself and many others are using typescript styling with success. If you have a specific problem, please file an issue so we can take a look.

For the record I'm referring to the scenarios described here. https://material-ui.com/guides/typescript/#usage-of-withstyl...

And this TS issue: https://github.com/Microsoft/TypeScript/issues/4881

The guide just comes off as a bunch of subpar workarounds.

Nothing shy of heroic efforts have gone into making such a comprehensive and wonderful-to-use library!

I look forward to seeing its future flourish!

Thanks to all who contributed.

A big thanks to the developers for this library. I've been using this with kotlin and react. Thanks for also including comprehensive typescript definitions. Great slibrary for spinning up web apps.

I've been using the pre-1.0 version for over a year, and recently switched to using the beta of the 1.0, and just want to say thanks — this is far and away the best UI kit I've come in contact with. It's well-designed, comprehensive, customizable, well-documented, and fun to work with. Great work!

Yup, big improvement over pre 1.0 as well. The old data table stuff in particular was pretty painful to use but that’s all been taken care of now. The only thing I’ve used that’s of similar quality to Material UI at this point is Vuetify, which still has a few rough edges

As someone who contributed to a very small part of this I know how hard the core maintainers worked and how patient they were, at least with my very long lived PR.

Thank you for staying the course and believing! What an EPIC effort!!!

Thank you for your effort and for supporting TypeScript.

Google announced their version of Material React (Alpha) at IO. "Material Components for React (MDC React)" Curious to see how it plays out with Material-UI. They should support Material-UI.

Congrats guys! It's been a pleasure using the pre 1.0 releases -- looking forward to trying 1.0 out.

In addition to the overall polish, one of my favorite aspects of this library is the authors' focus on controlling bundle size. Because of this library I learned that ES6 default imports may not be cheap.

VSCode users: consider checking out Import Cost extension [1] to keep an eye on this.

[1] https://marketplace.visualstudio.com/items?itemName=wix.vsco...

Unless I'm misunderstanding something, wouldn't Tree-Shaking remove the unnecessary code paths from each import? Assuming you're using Webpack 3+ that is.

Tree-Shaking (in Webpack 3+) is still somewhat conservative at the module level unless the dependent library also declares "sideEffects": "false" in package.json.

> Examples. We are hosting example projects with the most popular project starts: create-react-app, Next.js, Gatsby, CDN and Parcel.

"Example projects" link is broken. But the master branch seems to contain them: https://github.com/mui-org/material-ui/tree/master/examples

Thanks, it's fixed

Your weekly reminder that flat ui (and its derivatives, like material UI) are big steps backwards in usability:

https://www.nngroup.com/articles/flat-design/

Granting the validity of many aesthetic criticisms of over the top skeuomorphism, it will be a good day for users when the fashion-chasing flat ui era is over.

Material is slowly moving more in the "flat 2.0" direction that the article points out as fixing flat UI's usability problems. It's not fully there yet, but you can see aspects of it in say Google's floating add buttons in Calendar, Inbox, YouTube's search box, etc.

It is worth meditating on the fact that such a terrible idea was and is able to dominate the visual design community for so long without any significant push back. It has caused real pain for end users, and people who objected were shouted down or ignored.

All the more outrageous in an industry that likes to wear the mantle of empiricism.

The new Table APIs are fantastic. There used to be a lot of magic, but now all the selection handling is composable. Big props for the v1!

This is super cool - and the premium themes are very nice.

Just wanted to request for more react templates ... say an ecommerce site, etc. There's a burning need for this that is unserviced elsewhere.

That's absolutely the plan now that v1 has landed, along with Material Design v2 components and themes.

Material-UI has been designed with customisability in mind, so you can get the functionality of the components without necessarily having to look like Material Design.

how to follow this ?

> so you can get the functionality of the components without necessarily having to look like Material Design.

Great work, guys! Still bummed that you dropped Flow support, but I understand your reasoning. Definitely the most pleasurable UI toolkit to work with, and contributing is a blast.

I have been programming with Material UI, every day, for the past year and have nothing but very positive comments to make about it. The team is excellent, the code is extremely reliable, and the

https://github.com/cssinjs/jss

just works.

Its simple, easy to use, and not having to deal with global stylesheets is a pleasure.

And they are just getting started.

I look forward to the future with this React toolkit.

An incredible effort has been made by the team members.

This is a fantastic library and made it so much easier for a beginner like me to make stuff!

Congrats for the hard work ! This lib is a pleasure to use !

Congratulations on v1 and appreciate the efforts!

Just in time for my needs as I have been looking for other option besides Bootstrap, Fabric and Blueprint.

I'm liking 1.0 of MUI, but React's lifecycle method massacre has just made it impossible for us to move to v17.

Been using for a long time, but never realized that the product didn't reached v1 yet :) Great job.

A surprising lack of pictures in this article... One picture that shows the UI (one button)? Really?

Is there a demo that I don't need to download first?

You have demos for every material-ui components in the documentation.

https://material-ui.com/demos/app-bar/

I get that 'cssinjs' is now new and trendy but how can people legitimately pretend that the act of transcribing your css changes to their js format is anything but developer/designer hostile?

i can't be alone in mocking something up, then switching to browser to fine tune the css, then taking that back in to codebase.

Somebody in work also had the idea of storing every components styling in JSON, then getting the browser to render that as styling...so now you need to understand a JSON->CSS engine just to troubleshoot most styling issues?

When will it end. Do we need to rip out the DOM, HTML, JS & CSS and start over because we're creating more elaborate Rude Goldberg machines every couple of months.

Reply on news.ycombinator.com