consider moving from material-ui to react-toolbox
Opened this issue · 53 comments
material-ui is bloated & slow. the root cause is the crazy way styles are handled & the desire to stick with auto-prefix, which results in a net increase in payload (and means SSR is impossible). May be worth investigating and ultimately switching to https://github.com/react-toolbox/react-toolbox
Very good idea Matt and depending on my schedule I'll try to assist the best I can.
Sorry for not helping here, but I was checking Meatier stack as an alternative to Meteor and saw this issue. I'm using material-ui myself and, while it is more complete and "mature" than react-toolbox, I'm facing some slowness that made me worried. Do you think react-toolbox is significantly better?
I'm just testing and playing around, but I started creating some tabs, each with a Table inside (10 x 3 each). With only 3 tabs, the simple transitioning between them was clearly lagging, lacking responsiveness. Then I replaced the tables for lists and it improved, but there is still some lagging. When I test the same with empty divs, the transitions are smooth.
This crude analysis is subjective, of course, but I just decided to use it and I fear it may get ugly with more forms and lists for a more complex business webapp.
This issue just raised the question. I will try react-toolbox, will need some digging in things it's lacking (complete appbar, some components are not focusable, drawer can't be docked) but, depending on the outcome, I will follow your lead :)
I've done some work on react-toolbox upgrading them to Babel6 and doing webpack tweaks and in my opinion it's very solid set of react components albite quite undervalued from popularity perspective. Another up and coming start is Rebass. In terms of what's going to be popular with the corporate world, I'd put my vote on Grommet and React-Bootstrap
Bootstrap needs to die. I like react-toolbox, but I haven't played with it
too much. The code is readable, which is more than I can say about
material-ui. Ultimately, I'd like to write a wrapper for it so it could use
redux-operations to keep its entire state inside redux.
On Wed, Mar 9, 2016, 12:47 AM Bartek Kus notifications@github.com wrote:
I've done some work on react-toolbox upgrading them to Babel6 and doing
webpack tweaks and in my opinion it's very solid set of react components
albite quite undervalued from popularity perspective. In terms of what's
going to be popular with the corporate world, I'd put my vote on Grommet
http://www.grommet.io/ and React-Bootstrap
https://react-bootstrap.github.io/—
Reply to this email directly or view it on GitHub
#108 (comment).
Please don't switch to react-toolbox! material-ui feels way more responsive and smoother even though react-toolbox might've more components. It's also more par with the md design spec.
Do you have any specific examples of where it doesn't follow the MD spec
and where performance is worse? Everything I've played with has been much
more responsive than material ui, but I'm still pretty new to it.
Basically, we're gonna have to move away from material ui because they
don't support server side rendering. Currently, it's achieved via a really
ugly hack that disallows async on the server, and the maintainers would
rather double down on complexity instead of removing autoprefix, which
would greatly reduce client payload, client processing, and server
processing. When I see decisions like that, it's usually the writing on the
wall.
On Wed, Mar 9, 2016, 9:31 AM Mattias Ewers notifications@github.com wrote:
Please don't switch to react-toolbox! material-ui feels way more
responsive and smoother even though react-toolbox might've more components.
It's also more par with the md design spec.—
Reply to this email directly or view it on GitHub
#108 (comment).
I committed a material-ui removal, there are some styling issues caused by the change but nothing critical AFAIK.
I'm new to webpack so I only changed it enough to test react-toolbox, which needs webpack for it's SCSS imports. I didn't risk structuring it for a possible final version
About my previous test, I migrated my project to react-toolbox as well and while material-ui was slow and lagging with 3 tabs, I'm now able to open 10+ tabs with react-toolbox and there's no noticeable lag, very smooth indeed.
About react-toolbox having more components, actually the opposite is true. I'm missing a more complete app bar, sub-lists, better focus navigation, icons on tabs' header, among other things. But even if it is lacking some things, I believe react-toolbox's readability, performance and even using SCSS for theming instead of a custom implementation are things that made ME prefer it over material-ui, so I'll try to help improve it.
EDIT: Oh, and about the MD design spec, I agree that material-ui follows it better, but I'm sure react-toolbox will accept any PR that targets this. There are some things as zDepth, sub-lists, ripple effect on tab header, some other components missing, all things that can be fixed/added.
While material-ui looks good and they're getting everything right in terms of outcome, it has been a nuisance to work with on multiple occasions and I've ended up replacing it with react-toolbox on a couple of my projects. React-toolbox has been much easier to use and customize to my liking and needs.
I've been keeping an eye on meatier for a while and the use of material-ui has always been one of the downsides in my opinion, so I'm glad to see this issue being talked about. I support the change.
material-ui feels very laggy on mobiles and things like touching left navbar that opens properly on iphone have hard time with android phones. react-toolbox is not reponsive either on mobiles. But i think they have an issue open for it. theming and working with react-toolbox is nice considering I started with it as a beginner
why not just use vanilla material ui http://getmdl.io/ ? You can include only component that you need in your app?
http://getmdl.io/components/index.html#textfields-section
I feel like the getmld.io is a bit sluggish to the eye
http://www.material-ui.com/v0.15.0-alpha.1/#/components/text-field
http://react-toolbox.com/#/components/input
another up and coming challenger is nordnet-ui-kit
Nordnet has some cool things, but isn't Material Design.
There are https://github.com/garth/material-components, https://github.com/react-materialize/react-materialize and https://github.com/tleunen/react-mdl too.
Folks, there is no document that mention how to customize theme in react-toolbox. I would suggest getting one that has huge community. It only has 3k stars compared to getml.io vanilla JS, there are already close to 20k. Add on this will not couple directly with React, it can be used with any UI framework. Do you aware of any limitation of doing SSR with this?
@fallenpeace my eyes can't tell that. A clear benchmark would be helpful.
Folks, there is no document that mention how to customize theme in react-toolbox.
With toolbox-loader you can tell webpack where your configuration file is and it will prepend your config to each SASS build. This will result in your customized CSS for React Toolbox Components. For now you can browse the configuration files and override what you want.
https://github.com/react-toolbox/toolbox-loader
$color-primary: $palette-indigo-500 !default;
$color-primary-dark: $palette-indigo-700 !default;
$color-accent: $palette-pink-a200 !default;
$color-accent-dark: $palette-pink-700 !default;
$color-primary-contrast: $color-dark-contrast !default;
$color-accent-contrast: $color-dark-contrast !default;
$tooltip-max-width: 500px;
$tooltip-font-size: 1.2rem;
$font-weight-bold: 400;
I can't compare mdl with anything, since I haven't used it, but can say that toolbox > mui for sure.
Quick question why is SSR impossible?
Just found this.
@fallenpeace see https://github.com/mattkrick/meatier/blob/master/src/server/createSSR.js#L47
changing the node global for each request is not OK...
Request 1 comes in, sets global to Chrome
Request 1 hits a promise
Request 2 comes in, sets global to Firefox
Request 2 hits a promise
Request 1 gets a rendered route using the firefox user agent
Request 1 gets a crappy page that doesn't look right & never visits your site again
@mattkrick Ah, okay that makes a lot of sense, makes sense to move to something else then.
Although in the meantime, while we don't move away to an alternative, why dont we prefix for all user agents? Would prevent the crappy page effect. Specifically because browsers ignore prefixes not meant for them.
''all' to prefix for all user agents'
Thanks for the explanation by the way!
you certainly could, but that's just 1 reason to leave material-ui. for example, it still sends the prefixer to the client & the prefixer itself is larger than all the prefixes combined...so sending a prefixer + all prefixes isn't exactly a lean, production-ready approach. The project I'm working on right now is gonna have bespoke components that use react-look that should serve as a good example, although it doesn't use material design.
Is there a reason it won't adopt Material Design? I think there might be a niche for a React Material Design package without react-toolbox's SASS dependency or material-ui's performance issues. It would also be easier to get contributors, since there's a well-documented spec. Looks cool, too.
@mattkrick just curious, why do you hate Bootstrap so much? I don't love it, but I have to use it in my day job app (we use bootstrap-sass), and it's okay. I will say I'm not into react-bootstrap though, I made my own React components for it that are less verbose.
This confirms my long-standing suspicions that using only inline styles with React has been way overhyped.
ignoring that you can almost always identify a boostrap site without even opening the inspector...
- it's big
- it's invasive
- it's global
it was developed before the age of modular components & hasn't really evolved. css is a global beast, and we still don't have a good answer for it. My current thinking is an inline solution that turns into <style> tags. That way, you get the benefit of responsive media queries (this is where radium falls flat). Now that react-look is almost deprecated, I'm looking into aphrodite & fela as possible replacements.
I agree with what you're saying...the irony is we haven't had to deal with all this churn and deprecation :) Do you think the deprecation will end before the problems with CSS are fixed at the browser level?
The media queries you're talking about...are you saying they would be some kind of magic provided by the inline solution that responds to the element's own size, or just plain CSS @media queries that are responsive to the viewport size? I think people will realize @media queries with React are an antipattern, since many components have to be designed to display correctly anywhere in the component hierarchy, which requires them to respond to their own size.
so i think you're alluding to modular media queries, which is in the works (w3 i think).
until then, yeah, you want media queries that are written in native css, not inlined. Otherwise, you'll get a FOUC. that's why i can't really get behind radium, since it's all inline that doesn't write a stylesheet. I'd rather write in JS & have that transpile into a stylesheet.
Couldn't a react component that polyfills modular media queries prevent the FOUC by using visibility: hidden until the component has been mounted and measured?
modular media queries aren't a thing, yet. everything until then is just
kinda a hacky solution. using display hidden kinda sucks though, since you
don't know why nothing is showing up.
On Wed, Jul 20, 2016 at 12:51 PM, Andy Edwards notifications@github.com
wrote:
Couldn't a react component that provides modular media queries prevent the
FOUC by using display: hidden until the component has been mounted and
measured?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#108 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFQjv9Tm3Vuia7jDHXw4BZmP_AmkzrpUks5qXnw0gaJpZM4HrG3g
.
since you don't know why nothing is showing up
If written properly, the component is guaranteed to show up unless something throws an error before its second render, in which case it will be obvious what went wrong. It mounts with visibility: hidden, measures itself, and then gets re-rendered with visibility: visible. Sucks way less than global media queries
Plus you can often do something rational besides visibility: hidden. There might be a layout flash, but that's still a small price to pay for fake modular media queries (and/or JS calculated props responding to the size) in my mind
I don't know if anyone is working on standards for optionally laying out elements with JS, but I think that's the future of responsive design
it's just so much cleaner to have media queries live in css-land. That way, we don't have to worry about any of this. Fixing FOUCs is hard, when each of n modules can produce its own FOUC, you now have n FOUCs to worry about times x media query size bins.
That's why I hope browsers eventually support calling JS to perform the layout before the element mounts, so that it's possible without a FOUC. Have fun foregoing the convenience of libs like react-measure in the meantime.
FWIW, Material UI will be moving to JSS in the next release https://github.com/callemall/material-ui/milestone/14 which should resolve both performance issues, and issues with customisation. That said, the release has been under development since March and needs more devs to make it happen. There are per component issues that people can pick up and action
oh interesting! Personally, I went for Aphrodite over JSS, but they are both just fantastic.
@mattkrick I assume Aphrodite does autoprefixing better? Otherwise I'd want to use JSS to avoid compiling styles on the client at runtime.
@jedwards1211 as I understand it, they both prefix at runtime, but aphrodite buffers the writes to the DOM within the component render lifecycle, whereas JSS injects them all at once up front. assuming all your components load in sync, I'd assume that means aphrodite loads up the styles for all components into the buffer and them flushes those style updates to the DOM all at once, so performance should be about the same. It could be written to be a little more performant, but as is it's waaaaay faster than react-look, and I can't even find it on my CPU profiling, so I'd say it's good nuff for now.
Makes sense, nice!
I am also struggling with a UI framework. Material UI is obviously the most mature but the whole JS styling thing... is like we all know that is the future, but that future is not here right now. I am still waiting for that Redux moment, when all flux frameworks were reduced into one (pun intended)
Despite my love for Material UI and and JS styling, I still find plain old BEM + CSS a joy.
It might be due to my lack of experience, but I find plain CSS so much nicer to play / hack from the browser inspector. With Material UI I find it harder to reuse / style foreign components. If I stay within the framework everything is great, once I step out most likely third party components will be styled with CSS. I still have not found a way to implement my own universal set of styling directives with JS
@fgarcia Maybe somethig like https://github.com/rofrischmann/fela?
@javier-tarazaga the solution I like the best is StyledComponents they also have a great repo with one example styled in many ways
However I am specially fond of Material Design Lite mostly because it represents the best practices of plain old good CSS. There is a React port which is not very popular, but I like it a lot despite the rough edges. Since I do not have many years of styling experience, I want to learn well the basics of styling.
So far I would keep away from any inline solution until browsers improve the debugging experience of JS styling.
Hi! Owner of react-toolbox here! Just wanted to let you know I'm preparing a roadmap with a small manifesto and plans to migrate to an agnostic approach regarding styling. Best case scenario: you can create your own distribution with your own approach to styling. Also possible, let's see how the api results. Stay tuned :)
@javivelasco it would be great if you write the manifesto in a Gist, so other people could comment on it
I've tried so many React styling frameworks that I decided to write my own wrapper so it is easier for me to switch frameworks.
I thought I could cherry pick components from different frameworks. However in practice there are lots of problems. Right now my top priority is making sure that I use components which do not require or pull a whole framework along with them.
Of course. I'm publishing it in the repo and linked to a gist to gather feedback. It's not going to be a finished document, feedback is crucial.
Many of the comments about slowness, responsivity, performance, in-line styliing, etc, are from 1 year ago (March 2016 approx), what about today? Has improved MU or react-toolbox? I'm trying to decide which one to use, but I'm not sure if all that has been talk here is still relevant or the comments are being base on outdated versions
i think did or are going to move to jss for styles, which should speed things up greatly. currently i'm not using either in my daily work so i cant comment further
Looks like https://github.com/callemall/material-ui/pulse/monthly has merged 100+ pull requests in the last month (leaving only 2 open) while https://github.com/react-toolbox/react-toolbox/pulse/monthly has merged 0 pull requests leaving all 17 new requests open.
Material-UI had over 100 commits in the last month while React-Toolbox has had no commits in the last month.
React-Toolbox may have better project codebase, but without a large enough community behind it it seems to be paused while the original two creators work on other things.
react-toolbox has very poor a11y and it seems like accessibility is merely an afterthought than something that the project actually values.
@mattkrick Here is a little update on the v1 version of Material-UI that is coming. The core team have been working on the following improvements:
- A new CSS-in-JS solution with JSS, it's around 30% faster than what we used to have with inline-style without mentioning all the great features is unlocking.
- A 100% test coverage running on all the supported browsers as well as a large visual regression test suite.
- Accessible components
- Simpler implementation, hence lighter and faster.
- Self-supporting components (zero setup needed)
- Dynamic theme nesting
- Fully customizable components
- SSR support with optimized class names for production (
jss12, ...) - Flow and TypeScript definitions
material-ui is bloated & slow
@mattkrick It depends on the situation, looking at this benchmark Material-UI v0.x isn't that far from a raw implementation.
I read the whole issue and I would go with material-ui, besides the fact I prefer the way styling is handled in react-toolbox, the smaller community and maturity of the project has a huge impact in the future of the project itself.
This thread s awesome.
I got here through Google search where it ranks high.
I'm new to React and not a designer.
I was moving from old school HTML + CSS + JS + jQuery to React + Material-UI, and started to have trouble with MUI that remainded me of jQueryUI when to get a single gizmo working I needed to dive deep into a maze of project-specific sub-components & concepts. It seemed easier to write an own plugin.
One good thing here is that the thread mentions a number of toolsets which I looked at, checking first the age of the last commits.
After a short while I decided to go with Grommet.
It is more a set of controls that a framework.
It is created for React.
It has good usability on the developer's side, for example they showcase all the controls in a page while MUI requires hundreds of clicks to see them all. Grommet even has a storybook stuffed with examples for each and every visual control.
The storybook examples demonstrate the ease of use: all 20+ controls showcased in a 343LOC page.
They are not committed to the Material-UI thing (Google's attempt to make all sites equal?) (What will happen with MUI once Material gets that old-stuff smell?).
They already went V2 after noticing a number of issues.
I'm about to start with Grommet with expectation.