Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the librarie

Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the libraries often don't do as much as you think, and you'll spend more time customizing them than you would rolling your own. I think often I reach for a library because I don't understand how to solve a problem in react. It's better to first figure out how to solve the problem, then decide if you still want a library for it. The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components. One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas. Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.