The most common pattern in industry is to slather everything with libraries until you end up doing 10x the amount of work you needed to do. An actual 'good' ap

The most common pattern in industry is to slather everything with libraries until you end up doing 10x the amount of work you needed to do. An actual 'good' approach is to mostly utilise vanilla tooling like you suggest, but there are some exceptions, you can't be absolutist about it. I think for a decently sized web application, React (and only React, not all the cruft people usually include with it) will save you a lot of effort, and not using it would be a mistake. You could go with something like Vue instead but React does a much better job at abstracting away the huge amount of utility it provides. It has a smaller API surface by an order of magnitude. I think a good thought exercise is to think about what a 'perfect' implementation of the library you're thinking of using would look like for your exact use case, and compare it to using the actual library. Even if my use case doesn't include any performance requirements, I don't really think my implementation of a React-style solution would have less than 1k-2k LoC, and the implementation wouldn't be very simple. Contrast that to something like Redux which could be roughly implemented in ~20-100 LoC for most use cases and is conceptually very simple.