You’re not wrong. I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that alig

You’re not wrong. I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that aligns with what they’re building properly. For example, if you choose redux, why are you choosing it? Why choose it over the context api in react with built in state management, or zustand, jotai, or etc. In any stack you should be able to answer these questions, not just JS in the browser, but my experience is that a lot of JS teams haven’t determined this properly. It’s a recipe for struggle because they end up using more dependencies and in house code to band aid the fact that their tooling doesn’t work well with their software. The result is that the wrong dependencies and too many of them are used. This makes everything from building to testing to maintenance harder. A great goal on any team is to minimize the number of dependencies used in the first place; they’re often looked at as necessary to solve various problems, but they might not be at all. Some degree of trouble is inevitable because the JS world is kind of crazy, but it doesn’t have to be bad.