6 ms·

Even though I'm not completely satisfied with its state, I've recently picked Material UI over React Toolbox. Too bad React-MD wasn't around at the time because

by Egidius 10y ago

Even though I'm not completely satisfied with its state, I've recently picked Material UI over React Toolbox. Too bad React-MD wasn't around at the time because it seems like a fierce competitor at first glance. 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.

Klathmon 10y ago
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.
ergo14 10y ago
Wouldn't it be better for you to just throw in https://elements.polymer-project.org/browse?package=paper-elements 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?
- Egidius 10y ago
  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 https://www.npmjs.com/package/react-polymer
  - ergo14 10y ago
    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.
lilbobbytables 10y ago
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.
- Klathmon 10y ago
  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!
  - lilbobbytables 10y ago
    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.
    - MPiccinato 10y ago
      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 https://github.com/callemall/material-ui/issues/4066
ryanSrich 10y ago
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.
- Klathmon 10y ago
  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.
  - ryanSrich 10y ago
    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.
    - Klathmon 10y ago
      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.
renshenhe 10y ago
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.
- harlanlewis 10y ago
  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.

by Egidius 10y ago

Klathmon 10y ago

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.

ergo14 10y ago

Wouldn't it be better for you to just throw in https://elements.polymer-project.org/browse?package=paper-elements 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?

Egidius 10y ago
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 https://www.npmjs.com/package/react-polymer
- ergo14 10y ago
  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.

lilbobbytables 10y ago

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.

Klathmon 10y ago
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!
- lilbobbytables 10y ago
  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.
  - MPiccinato 10y ago
    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 https://github.com/callemall/material-ui/issues/4066

ryanSrich 10y ago

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.

Klathmon 10y ago
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.
- ryanSrich 10y ago
  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.
  - Klathmon 10y ago
    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.

renshenhe 10y ago

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.

harlanlewis 10y ago
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.