Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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


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.


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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: