React-MD – React components built with Sass(react-md.mlaursen.com)
react-md.mlaursen.com
React-MD – React components built with Sass
https://react-md.mlaursen.com/
58 comments
Have you run into any significant issues with the overhead of "bloat" that comes with inline styles? Injecting so many styles inline especially for complex list items might potentially have some performance issues despite having a virtual dom.
I have been considering refactoring my personal ui lib to use css for static styles with css modules while all themable/dynamic styles inline. Many might say the mixture gets increasingly complex scaling but I have not run into such an issue.
I have been considering refactoring my personal ui lib to use css for static styles with css modules while all themable/dynamic styles inline. Many might say the mixture gets increasingly complex scaling but I have not run into such an issue.
This is a very fair point. We've followed a similar approach to what you're considering, with styles living in a couple places:
- Scss library of variables, mixins, and functions that can be imported in whole or piece-by-piece into components that can use them. Doesn't compile any CSS classes on its own.
- A lean global “browser reset”, uses some of the global style variables from the library.
- A simple React component (we call it `Cell`) that is used absolutely everywhere. This component has its own .scss file which imports the global scss library, and is essentially a one-stop-shop for `functional` CSS for colors, dimensions, typography, elevations (drop shows and zindexes), scrolling, etc. React authors use it via props instead of writing class names. Eg `<Cell color='action-primary' elevation={2} fontFamily='header'>`. Heavily reusing this component is what most directly addresses the performance concerns you note.
- While Cell is sufficient for composing most layout and aesthetics at all levels of the page, one-offs are often needed for fine detail work:
--- Simple cases are handled directly where needed via inline styles (easy to read when everything is in one place). We don't do anything fancy here for authoring (no radium etc), just an inline style autoprefixer that runs through postcss loader via webpack.
--- Per-component scss files for more complicated needs (unique animations, novel compositions, complex interactions, etc). The component scss imports the global scss library so all our standard theme/helpers/etc are available everywhere. The component scss outputs to unique hashed classnames via webpack, so there is no risk of class name collisions between components. This allows for very focused scss files with short, straightforward names.
A lot of this works very well - in particular the global scss library, the Cell component, and the ability to opt-in to more fine grained control per component. However, there is some duplication between the scss library and a few javascript utils we've made to help keep inline styles consistent. These issues are somewhat made up for by how transportable our style layer is - if we were to switch away from React, or start a new project on a different stack, having the style vars and class library defined in scss already would make it easy to simply drop in and get rolling.
- Scss library of variables, mixins, and functions that can be imported in whole or piece-by-piece into components that can use them. Doesn't compile any CSS classes on its own.
- A lean global “browser reset”, uses some of the global style variables from the library.
- A simple React component (we call it `Cell`) that is used absolutely everywhere. This component has its own .scss file which imports the global scss library, and is essentially a one-stop-shop for `functional` CSS for colors, dimensions, typography, elevations (drop shows and zindexes), scrolling, etc. React authors use it via props instead of writing class names. Eg `<Cell color='action-primary' elevation={2} fontFamily='header'>`. Heavily reusing this component is what most directly addresses the performance concerns you note.
- While Cell is sufficient for composing most layout and aesthetics at all levels of the page, one-offs are often needed for fine detail work:
--- Simple cases are handled directly where needed via inline styles (easy to read when everything is in one place). We don't do anything fancy here for authoring (no radium etc), just an inline style autoprefixer that runs through postcss loader via webpack.
--- Per-component scss files for more complicated needs (unique animations, novel compositions, complex interactions, etc). The component scss imports the global scss library so all our standard theme/helpers/etc are available everywhere. The component scss outputs to unique hashed classnames via webpack, so there is no risk of class name collisions between components. This allows for very focused scss files with short, straightforward names.
A lot of this works very well - in particular the global scss library, the Cell component, and the ability to opt-in to more fine grained control per component. However, there is some duplication between the scss library and a few javascript utils we've made to help keep inline styles consistent. These issues are somewhat made up for by how transportable our style layer is - if we were to switch away from React, or start a new project on a different stack, having the style vars and class library defined in scss already would make it easy to simply drop in and get rolling.
Interesting insights, though I wish much of these practices to be viable outside of closed source.
-A Scss library for functionality rather than compiling definitely seems interesting as a halfway point between pure css or pure javascript.
-When I was using pure inline-styles I rarely ran into cases where I couldn't get away with using divs or other style-less elements. The downside was div soup and bloat when rendering large quantities of components that had resets.
-I would be very interested, if allowed, to see the design of your Cell component. Rather than a component itself I find it simpler to define certain highly reused styles in the global scope, such as grid layout. Styles like these generally don't need encapsulation and are highly reusable since they are mainly containers.
-
--I must admit that prefixed inline-styles are atrocious to look at it definitely is enjoyable dealing with a component in roughly a single file. Big loss was targeting an n:child for styling
--Since I don't write any production code I can get away with the web animation api or any resource still in early stages or have not been highly adopted yet. I generally have a prefix for the global css classes e.g. 'qp-grid' and my projects are hardly big enough to have naming collisions.
It is unfortunate mixing css and inline-styles make it quite difficult to apply to an open source lib but I am quite hopeful for a solution or practice to address the issues.
-A Scss library for functionality rather than compiling definitely seems interesting as a halfway point between pure css or pure javascript.
-When I was using pure inline-styles I rarely ran into cases where I couldn't get away with using divs or other style-less elements. The downside was div soup and bloat when rendering large quantities of components that had resets.
-I would be very interested, if allowed, to see the design of your Cell component. Rather than a component itself I find it simpler to define certain highly reused styles in the global scope, such as grid layout. Styles like these generally don't need encapsulation and are highly reusable since they are mainly containers.
-
--I must admit that prefixed inline-styles are atrocious to look at it definitely is enjoyable dealing with a component in roughly a single file. Big loss was targeting an n:child for styling
--Since I don't write any production code I can get away with the web animation api or any resource still in early stages or have not been highly adopted yet. I generally have a prefix for the global css classes e.g. 'qp-grid' and my projects are hardly big enough to have naming collisions.
It is unfortunate mixing css and inline-styles make it quite difficult to apply to an open source lib but I am quite hopeful for a solution or practice to address the issues.
What made you choose Material UI over React Toolbox?
I'm starting a project that is more or less material, and this post of making me realize it could definitely use a number of material UI elements.
I'm starting a project that is more or less material, and this post of making me realize it could definitely use a number of material UI elements.
I'm not sure if you are looking for other opinions, but I'm looking for something to move away from react toolbox.
It's too difficult to overwrite styles, they are changing their style "system" for the 3rd time in under a year right now (SASS -> postCSS), and the lead maintainer has started posting updates both minor and a major bump without any kind of changelogs or info on what changed, and there is no real roadmap to speak of.
I hate being overly critical of FOSS projects, especially ones where it's clearly a passion project, but I can't rely on React Toolbox any more in a professional way. If it were a smaller library i'd be more okay with it, but the "theme" or "UI framework" of our application is not something easily replaced, so it becomes a bit more important.
I shied away from Material-UI as inline styles just won't work for us for a bunch of reasons, and they aren't far enough along their "conversion" to the new style system at this time for us to take it on faith, so we struck that down too.
This library is looking like a good replacement. If some of those performance issues aren't the libraries fault and are the "app maintainers" fault (in this case the same person, but the main dev has told me that it's because he was lazy when making the docs website that it's sluggish), then it's looking like it'll be a winner!
It's too difficult to overwrite styles, they are changing their style "system" for the 3rd time in under a year right now (SASS -> postCSS), and the lead maintainer has started posting updates both minor and a major bump without any kind of changelogs or info on what changed, and there is no real roadmap to speak of.
I hate being overly critical of FOSS projects, especially ones where it's clearly a passion project, but I can't rely on React Toolbox any more in a professional way. If it were a smaller library i'd be more okay with it, but the "theme" or "UI framework" of our application is not something easily replaced, so it becomes a bit more important.
I shied away from Material-UI as inline styles just won't work for us for a bunch of reasons, and they aren't far enough along their "conversion" to the new style system at this time for us to take it on faith, so we struck that down too.
This library is looking like a good replacement. If some of those performance issues aren't the libraries fault and are the "app maintainers" fault (in this case the same person, but the main dev has told me that it's because he was lazy when making the docs website that it's sluggish), then it's looking like it'll be a winner!
Klatmon, I'm the author and lead maintainer of react-toolbox.com. I want to put you a bit more in context to understand what's going on.
The library is originally, and still, built with SASS. We've migrated already to PostCSS (there is a beta published) to fix issues regarding customization and building. I'm releasing a new package in a couple of days so you will see the reasoning behind this migration.
Cutomization is a problem really difficult to solve and it needs dedication. I'm putting a lot of effort on it but I can't review issues, solve doubts, fix bugs, work on new components, maintain the docs site, release new versions, keep dependencies updated, writing changelogs... and at the same time figuring out how to solve major problems like customization and workflow.
I'm one person without any funding or retribution. I have no help apart from sporadic contributions and some people helping with issues from time to time. I also have a full time job that keeps me away from dedicating as much time as I wanted.
Instead of being critical (and to hate being critical), you can contribute to the project. There is no need to write code or to fix bugs to contribute. It's enough responding issues, solving doubts... But please, don't be unfair. Open Source is built by everyone. If you see weaknesses, just try to help fix them, not just pointing at them. :)
About the changelog... there are no breaking changes, no major releases. You can see what's changing just by checking out the git history. I get is easier to check a note with the highlights but I need to assign priorities to move on. In any case I want to let you know that I plan to release a roadmap, along with an article and a new package during the next week.
The library is originally, and still, built with SASS. We've migrated already to PostCSS (there is a beta published) to fix issues regarding customization and building. I'm releasing a new package in a couple of days so you will see the reasoning behind this migration.
Cutomization is a problem really difficult to solve and it needs dedication. I'm putting a lot of effort on it but I can't review issues, solve doubts, fix bugs, work on new components, maintain the docs site, release new versions, keep dependencies updated, writing changelogs... and at the same time figuring out how to solve major problems like customization and workflow.
I'm one person without any funding or retribution. I have no help apart from sporadic contributions and some people helping with issues from time to time. I also have a full time job that keeps me away from dedicating as much time as I wanted.
Instead of being critical (and to hate being critical), you can contribute to the project. There is no need to write code or to fix bugs to contribute. It's enough responding issues, solving doubts... But please, don't be unfair. Open Source is built by everyone. If you see weaknesses, just try to help fix them, not just pointing at them. :)
About the changelog... there are no breaking changes, no major releases. You can see what's changing just by checking out the git history. I get is easier to check a note with the highlights but I need to assign priorities to move on. In any case I want to let you know that I plan to release a roadmap, along with an article and a new package during the next week.
Hey javivelasco,
I want to start off by saying I didn't mean for anything I said to come across as bad mouthing you as a person or a developer, or your work. I was trying to give my experience and what we were looking for/having issues with.
I fully understand that this is largely a passion project for you. It's a fantastic library, and I really mean that. It's a project that I like to point people to when they want to see an example of a well put together ES2015+ setup. And without your library we would have either rolled our own which would have taken a pretty significant amount of time and wouldn't have been as polished or tested, or we would have went with Material-UI which would have had a tough learning curve to us who are used to CSS and SASS.
That being said, we are still looking at options for replacement of React-Toolbox in it's current form (or perhaps just a change in how it's used). As you said, styling and customization is a really difficult problem to solve. I haven't used any other react UI libraries in any major way, so i'm not sure if this is the best or if it's just not a good fit for us, but we felt the pain from trying to customize styles and started looking. I didn't mean to have it come across so negative, and I apologise for that. Rereading it now it's just a list of complaints, and I generally try to avoid doing that (although clearly not well enough).
I have contributed in a very small part to React-Toolbox through a few bugfixes and very small PRs, but not in any significant way. I opened an issue[0] this week about the issues we have been having with updates without changelogs and the lack of direction. I'm willing to help, but I need some direction on how you want that help. I get that it's tough to prioritise and that some things need to fall through (Prioritization is my worst skill, I am terrible with it and have to lean on others all the time to help me, so I know this all too well!), but at the least I just wanted some information on if this was intentional, a mistake, that I was missing something, just an oversight or something else.
I know you think there aren't any breaking changes, but to me updates without any kind of information on why or what was fixed or changed are an issue. For example, a change you made almost a month ago added a default `type="button"` to all button elements. This broke all of our forms where we were relying on that. We saw that forms didn't work correctly when updating, but didn't have time to look into why so we held back the version. I spent an hour or so looking through commit logs to see if anything jumped out at me, so then I started to look through a log of the code that changed, however since there were over 80 commits between 1.2.5 and 1.3.0, I gave up looking since it would have taken more time than I had at the moment. Finally just today I stumbled upon an issue[1] where you explained what and why it was changed.
That's something where if there were a line along the lines of "added property `type` to buttons (defaults to "button"). Done to avoid having every button submit a form." it would have saved us a few hours at least. And in 5 or so minutes the fix was made for our codebase and we can update. It's a small thing in the end, but it's just one of many little issues we have felt like that, and often times there is already a fix, but it's hidden in github issues under strange titles and they take a long time to find.
This ended up getting a lot longer than I thought it would, so to close it up...
I'm very much looking forward to the roadmap/article you will be releasing, and I am still more than willing to help with changelogs, documentation, testing, or even some light features/fixes. I really do like the library, it's a large part of our app that has saved us a significant amount of time. So thank you.
[0] https://github.com/react-toolbox/react-toolbox/issues/1043
[1] https://github.com/react-toolbox/react-toolbox/issues/953
I want to start off by saying I didn't mean for anything I said to come across as bad mouthing you as a person or a developer, or your work. I was trying to give my experience and what we were looking for/having issues with.
I fully understand that this is largely a passion project for you. It's a fantastic library, and I really mean that. It's a project that I like to point people to when they want to see an example of a well put together ES2015+ setup. And without your library we would have either rolled our own which would have taken a pretty significant amount of time and wouldn't have been as polished or tested, or we would have went with Material-UI which would have had a tough learning curve to us who are used to CSS and SASS.
That being said, we are still looking at options for replacement of React-Toolbox in it's current form (or perhaps just a change in how it's used). As you said, styling and customization is a really difficult problem to solve. I haven't used any other react UI libraries in any major way, so i'm not sure if this is the best or if it's just not a good fit for us, but we felt the pain from trying to customize styles and started looking. I didn't mean to have it come across so negative, and I apologise for that. Rereading it now it's just a list of complaints, and I generally try to avoid doing that (although clearly not well enough).
I have contributed in a very small part to React-Toolbox through a few bugfixes and very small PRs, but not in any significant way. I opened an issue[0] this week about the issues we have been having with updates without changelogs and the lack of direction. I'm willing to help, but I need some direction on how you want that help. I get that it's tough to prioritise and that some things need to fall through (Prioritization is my worst skill, I am terrible with it and have to lean on others all the time to help me, so I know this all too well!), but at the least I just wanted some information on if this was intentional, a mistake, that I was missing something, just an oversight or something else.
I know you think there aren't any breaking changes, but to me updates without any kind of information on why or what was fixed or changed are an issue. For example, a change you made almost a month ago added a default `type="button"` to all button elements. This broke all of our forms where we were relying on that. We saw that forms didn't work correctly when updating, but didn't have time to look into why so we held back the version. I spent an hour or so looking through commit logs to see if anything jumped out at me, so then I started to look through a log of the code that changed, however since there were over 80 commits between 1.2.5 and 1.3.0, I gave up looking since it would have taken more time than I had at the moment. Finally just today I stumbled upon an issue[1] where you explained what and why it was changed.
That's something where if there were a line along the lines of "added property `type` to buttons (defaults to "button"). Done to avoid having every button submit a form." it would have saved us a few hours at least. And in 5 or so minutes the fix was made for our codebase and we can update. It's a small thing in the end, but it's just one of many little issues we have felt like that, and often times there is already a fix, but it's hidden in github issues under strange titles and they take a long time to find.
This ended up getting a lot longer than I thought it would, so to close it up...
I'm very much looking forward to the roadmap/article you will be releasing, and I am still more than willing to help with changelogs, documentation, testing, or even some light features/fixes. I really do like the library, it's a large part of our app that has saved us a significant amount of time. So thank you.
[0] https://github.com/react-toolbox/react-toolbox/issues/1043
[1] https://github.com/react-toolbox/react-toolbox/issues/953
That's perfect, thanks!
I've only given each of them a brief look this morning. I certainly would not have gathered that about react-toolbox - and those among the kinds of issues that really tend to bother me.
Also, for Material-UI, I don't particularly like the idea of relying so heavily on inline styles and already know where it will cause some issues in the future of this project.
I've only given each of them a brief look this morning. I certainly would not have gathered that about react-toolbox - and those among the kinds of issues that really tend to bother me.
Also, for Material-UI, I don't particularly like the idea of relying so heavily on inline styles and already know where it will cause some issues in the future of this project.
It is worth noting that Material-UI is moving away from inline styles in favor of JSS. Checkout their Next branch and discussion about it: https://github.com/callemall/material-ui/issues/4066
Check out the material-ui `next` branch. It isn't released but I'm using it (and publishing my own private package) for a soon to be production application. While not all components are ported, it has enough to use, run the `docs/site` and see for yourself. The next branch seemingly takes all the complaints from the current release and solves them - really a pleasure to use.
Honest question. Wouldn't you be better off constructing your own style architecture for an application so complex it requires React? I imagine using any prebuilt UI framework out of the box becomes restrictive with the necessity to constantly rewrite styles to match whatever the design team wants. I'm just curious to hear how teams use things like this.
I found we really didn't have to rewrite anything big.
The components that are given are "building blocks" Buttons, "cards", dialogs, text input fields, etc...
Once you get them, you can just override the color, size, shape, and sometimes a few other little things and it "just works".
So I don't need to worry about getting an input box to correctly style on all platforms, I don't need to come up with the animations and JS to make the fancy "floating input field" or the inky splash effects or the 2-step shadows.
That's also why the issue around styling these things is so contentious. It's a major way that you'll be interacting with them, and with the way CSS works it's not easy to "overwrite" default styles without using !important which feels like using a sledgehammer to crack an egg.
The components that are given are "building blocks" Buttons, "cards", dialogs, text input fields, etc...
Once you get them, you can just override the color, size, shape, and sometimes a few other little things and it "just works".
So I don't need to worry about getting an input box to correctly style on all platforms, I don't need to come up with the animations and JS to make the fancy "floating input field" or the inky splash effects or the 2-step shadows.
That's also why the issue around styling these things is so contentious. It's a major way that you'll be interacting with them, and with the way CSS works it's not easy to "overwrite" default styles without using !important which feels like using a sledgehammer to crack an egg.
Interesting. I agree, not having to reinvent wheels is always good. In my experience there's a lot to fight with frameworks like Foundation, Bootstrap, and even Material. If you're all in philosophically then I suppose there wouldn't be much to change, but if you disagree on certain UI principles there's going to be rough times ahead.
I think the difference is that in our case we were looking for handholding, and a UI toolkit gave us that.
We aren't designers, and being developers we have a tendency to nitpick which is only worse when the subject is just outside our area of expertise...
Picking a design "platform" and using a toolkit to implement it pretty much stopped most of that in it's tracks and let us focus on the actual application.
It's obviously not for everyone, but it was exactly what we wanted and needed.
We aren't designers, and being developers we have a tendency to nitpick which is only worse when the subject is just outside our area of expertise...
Picking a design "platform" and using a toolkit to implement it pretty much stopped most of that in it's tracks and let us focus on the actual application.
It's obviously not for everyone, but it was exactly what we wanted and needed.
Another great feature of React-MD, fully accessible.
I haven't had time to fully test that claim yet with a screen reader, but it does seem to work well using the key oars alone which is something often overlooked.
I haven't had time to fully test that claim yet with a screen reader, but it does seem to work well using the key oars alone which is something often overlooked.
Wouldn't it be better for you to just throw in https://elements.polymer-project.org/browse?package=paper-el... ? They are all tested and probably most feature complete implementation of material design, I think web components can work with react?
I'm pretty sure I don't want to go down that road for an application that's meant to go into production (some day). It's possible to use Polymer elements in react. There's even a npm package[1] for it, but merely by looking at the activity of the package I'd already choose not to use this for a production application other than my own. Furthermore: I've tried Polymer and it offers its own data-binding implementation. I don't want to have multiple UI layers and two ways of data-binding. That's just asking for trouble.
[1] https://www.npmjs.com/package/react-polymer
[1] https://www.npmjs.com/package/react-polymer
Wouldn't passing things from react -> custom element be the same as to any other react component?
Web components are like any other dom nodes - they should not conflict.
What I like about this library over Material UI is the complete separation of styling, I really don't like how styles are written and passed as an object in Material UI and the requirement of getting muiTheme() from context for most components is just maddening, especially painful during testing. But what I'd really like to see from a material ui library is one that uses ITCSS for styling, check out the grommet UI library which is just an amazing library to work with, and the ITCSS makes editing and customising components a breeze.
Check out the material-ui `next` branch. It uses JSS and is much easier to customize.
Nothing to do with this project per se, but I still do not understand the deal with material design on the web. I can understand the case for it's use in small screens and maybe falling back to it based on media queries makes sense but I'm yet to see a good looking website on a laptop using material design.
I tend to enjoy it, mostly because it's a good "baseline". The phrase "nobody ever got fired for choosing IBM" comes to mind.
It might not be the most beautiful, it might not be the most information-dense, it might not be something that an actual designer would want to implement everywhere, but it works consistently, and it works pretty well on all screen sizes and shapes and input types.
It's a set of guidelines to hold your hand in making something that's not terrible even if you have literally no design experience, and I think it's doing a great job in that.
But, I also really like the look of MD. The animations, the "inky" taps, the shadows, the movement. It looks nice to me, it helps give a sense of "where" parts of the app live, and it tends to be consistent enough that if I notice an app doing it, I can generally grasp the "where would I go for this" much faster than other designs.
It might not be the most beautiful, it might not be the most information-dense, it might not be something that an actual designer would want to implement everywhere, but it works consistently, and it works pretty well on all screen sizes and shapes and input types.
It's a set of guidelines to hold your hand in making something that's not terrible even if you have literally no design experience, and I think it's doing a great job in that.
But, I also really like the look of MD. The animations, the "inky" taps, the shadows, the movement. It looks nice to me, it helps give a sense of "where" parts of the app live, and it tends to be consistent enough that if I notice an app doing it, I can generally grasp the "where would I go for this" much faster than other designs.
I generally like Material Design, but sadly I have to agree with you.
Contrary to Bootstrap, you can't just drop in Material Design and expect it to look decent. You actually have to adhere to the design and usage guidelines that come with Material Design to really make something good looking and functionally coherent with it.
Contrary to Bootstrap, you can't just drop in Material Design and expect it to look decent. You actually have to adhere to the design and usage guidelines that come with Material Design to really make something good looking and functionally coherent with it.
Even from a purely philosophical perspective I have a great appreciation for material design. Even if it's not their intent, they're normalizing and standardizing art / design for non-artists and non-designers. Sounds like a pretty ambitious thing to me. I hope they succeed with it.
The ordering website i am working for a client uses many material design ideas. We do have good feedback from the end users.
One thing the author has pointed out on reddit was that many of the components have a property to wait to fire until the ink animation is done.
That looks like the cause of the delay and "sluggish" feeling some people are reporting. If you don't set that prop, it's very quick even on a nexus 4 which tends to be my baseline device for "web apps" right now.
Why you'd want to set that I'm not sure, but it's there.
That looks like the cause of the delay and "sluggish" feeling some people are reporting. If you don't set that prop, it's very quick even on a nexus 4 which tends to be my baseline device for "web apps" right now.
Why you'd want to set that I'm not sure, but it's there.
Did the author try to use the components from a low end phone? Generally it looks good but all the jumping, flashing and crashing do not signal version 1.0.0.
Totally. 64% of my users are on mobile. Can one really afford to ignore that crowd?
Of course, mobile web development is, as I tend to say, the IE6 of modern days. So many older devices, and we also need to more or less support all of them.
Graceful degradation is the key, yes, but React-MD doesn't even seem to cope well with high-end devices.
Of course, mobile web development is, as I tend to say, the IE6 of modern days. So many older devices, and we also need to more or less support all of them.
Graceful degradation is the key, yes, but React-MD doesn't even seem to cope well with high-end devices.
Perhaps the name could be re-thought? I expected something Markdown related.
This is awesome! Any plans for TypeScript support?
Looks like that might happen: https://github.com/mlaursen/react-md/issues/175
I would be curious to know how this compares to Material UI.
Has anyone tried both?
Somewhat relevant: It seems like Google is using [1] for some of their projects...
[1] https://getmdl.io/showcase/index.html
[1] https://getmdl.io/showcase/index.html
Huh? This is a list of sites that use Material Design Light, which is not React-MD. Also, I don't Google even uses React.
Wow very pretty. I love material design.
sweet, I have just yesterday implemented MaterialUI to my react app... I will change it asap :)
Am I the only one who thinks Material Design and its derivatives is just plain ugly? If I see a website created with this style, I press Ctrl+W close to speed of light.
Huge number of sites in material ui style are built using super broken widget libraries to boot -- nothing is as frustrating as a form that can't be completed due to ui broken ness ...
I want to like MD because there are some great tool kits out there, but the animations come off as unnecessary, and often result in slowness and flicker on first loads from my experience.
No you're definitely not the only one. Material design is hideous.
It's not so much ugly as it is unusable, there's just way too much whitespace.
My thoughts exactly! Glad I'm not the only one.
It probably makes sense in Google's own ecosystem of apps, but as an aesthetic style it seems to be intentionally bland and tasteless.
I think you can defend your use of the word 'bland' here but 'tasteless'? That seems a little overblown.
Nope, not the only one :-)
My opinion is somewhere in between neutral and "I quite like it". I think I'm beginning to feel rather numbed to it and would like to see a people add their own fresh twist - but I very much like the overall aesthetic approach in it's various forms (as long as it doesn't sacrifice affordance[0] at the altar of flatness)
[0] https://www.interaction-design.org/literature/book/the-gloss...
[0] https://www.interaction-design.org/literature/book/the-gloss...
Grotesque, yet my designer friend says it is amazing. Marmite it seems.
* quite the paradox writing this on HN isn't it? I think we browse looking for the content not the design. Google cloud? Angular.io? android.com? stamplay.com?
What about it makes it ugly? I'm curious where the visual dissonance is for you in a set of guidelines that generally plays to the masses.
what a slow, clumsy, and flickering website of a modern ui framework
~deleted~
Because even their CSS implementation will still be css-in-js, not to mention that this framework seems to be going in a slightly different direction than material-ui.
Not everything can be done in a PR. I doubt the callmeall people would enjoy someone switching them to SASS, or rewriting some of their components entirely to work with a keyboard easier, or any other major changes.
And what is "half baked" about this? Besides being newer, it doesn't look any worse to me at first glance.
Not everything can be done in a PR. I doubt the callmeall people would enjoy someone switching them to SASS, or rewriting some of their components entirely to work with a keyboard easier, or any other major changes.
And what is "half baked" about this? Besides being newer, it doesn't look any worse to me at first glance.
[deleted]
Things I like about React MD over Material UI: * Fully tested * Separation of styles * Grid included
On a sidenote: the page's styling messes up during loading. It takes one second before it morphs into the actual state.