Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have

Absolutely agree, I have just started a new project which is the first time I have used React beyond a "toy" project (along with Typescript and Redux), and have found by far the best approach is to start off with just the basics (i.e. React alone), and only add in additional libraries when you start hitting problems you feel could be solved in a more optimal manner (e.g. Redux when state management starts getting messy, then redux-form when you realise form onChange handlers etc. are a bit tiresome to write, etc.). It does help to have a good awareness of what libraries are being released and are becoming popular before you start needing them however, so you can realise when you are facing a problem that has already been solved - it helps if you read the React-related stuff that appears on HN and follow a few of the "key players" on Twitter. The big starter projects are a great resource for code examples of how pieces fit together and for pointing you in the direction of other interesting libraries, but are just too overwhelming to work with if you aren't already familiar with the core components of the stack. One thing I am enjoying a lot about the React world (compared to the Angular world, in my case) is that each library/component tends to be pretty simple (for example, the APIs are pretty small) and you can reason about what it is doing in your head; but the way they fit together can make solving complicated problems feel really easy once you get your head around the React/Redux (or whatever) approach to breaking things down. I feel like I have a much better understanding of what is going on under the hood with the application than I did with Angular, and this makes solving hard problems much easier, even if it means more setup and lines of code initially.