consider moving from material-ui to react-toolbox

[mattkrick]

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

[bartekus]

Very good idea Matt and depending on my schedule I'll try to assist the best I can.

[renato]

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?

[mattkrick]

@renato what kind of slowness?

[renato]

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 :)

[bartekus]

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

[mattkrick]

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 [email protected] 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 https://github.com/mattkrick/meatier/issues/108#issuecomment-194141564.

[mtsewrs]

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.

[mattkrick]

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 [email protected] 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 https://github.com/mattkrick/meatier/issues/108#issuecomment-194347803.

[renato]

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.

[ktmn]

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.

[fortm]

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

[cometta]

why not just use vanilla material ui http://getmdl.io/ ? You can include only component that you need in your app?

[fallenpeace]

@cometta

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

[bartekus]

another up and coming challenger is nordnet-ui-kit

[renato]

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.

[cometta]

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.

[ktmn]

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.

[fallenpeace]

Quick question why is SSR impossible?

Just found this.

https://github.com/callemall/material-ui/blob/0951d951c1cdf86fe3af44aff6432fdb2799564c/docs/src/app/components/pages/get-started/serverRendering.md

[mattkrick]

@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

[fallenpeace]

@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!

[mattkrick]

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.

[wtgtybhertgeghgtwtg]

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.

[jedwards1211]

@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.

[jedwards1211]

This confirms my long-standing suspicions that using only inline styles with React has been way overhyped.

[mattkrick]

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.

[jedwards1211]

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.

[mattkrick]

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.

[jedwards1211]

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?

[mattkrick]

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 [email protected] 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 https://github.com/mattkrick/meatier/issues/108#issuecomment-234061699, or mute the thread https://github.com/notifications/unsubscribe-auth/AFQjv9Tm3Vuia7jDHXw4BZmP_AmkzrpUks5qXnw0gaJpZM4HrG3g .

[jedwards1211]

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