1990s advice on a 1990s website. It's the opposite. We need to move away from package hell by splitting our work in two opposite directions: on the one hand, we should move back to large, effective standard libraries; on the other hand, we should move toward more services, fewer library packages. A project shouldn't need more than a few packages, usually for something like a database connection protocol. Working with libraries is the worst part of the job.
This is one of the worst ideas I've ever read on this site. But I'm glad you wrote it, as this is the epitome of a sentiment I've many times seen lurking.
- Standard libraries always go bad over time as idioms change and they don't have a policy for breaking changes
- Services do not compose as easily as libraries. Composition is key to code reuse.
I understand most off the industry deals with terrible libraries, and many of you long for simpler times, but the proliferation of complexity will occur with or without the NPMs of the world, as the industry grows and functions in a economy that doesn't care about externalities, including endemic stupid extra complexity.
I am trying to maintain an absolute pile of shite because the previous lead dev needed to reinvent every wheel in an undocumented untested way. On boarding developers takes longer. Bugs are more difficult to fix.
You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.
