Medium

One should not spend the time to find the optimal solution for a problem that was already solved. Instead, one should focus on what is important for the business, instead of trying to solve computer science problems that don't add any value. Reinventing the wheel is a waste of time and effort.

The difference here is that you should be capable of writing that optimal solution given enough time and effort, including being able to test thoroughly. The problem happens when you are a beginner that doesn't understand why a solution you are using works. If you understand how that works and somebody else wrote the code and tests for you, then use that and don't lose your time.

Using third-party code is a bigger problem with full featured frameworks or libraries, where abstractions leak and you can't fix it. In single atomic modules you don't have this problem because the scope is so small that instead of designing with the Open/Closed principle you design a closed module that will never change, then the extensibility lies in your application.

Efficient abstractions are not about lines of code, it is about separation of concerns and implicit reusability. It is not an easy thing to do, that's why we find crap sh1t everywhere, but just because it is not easy, doesn't mean it is not worth it. If you only think about abstractions when your code is bigger, you will have a hard time to fix it because then you are not thinking about separating the concerns, you are thinking about reducing characters, which is something totally different and suboptimal.

The actual problem with NPM is the sum of lack of discovery and too much trust in the publisher. We should focus on the relevant problems and try to fix these problems, instead of trying to push to everyone that the best and efficient engineering principles are wrong, without being able to provide at least one single reasonable evidence that could help the community to evolve.

Less is more, at least if the dev knows what the hell is going on.