| You spend brain cycles trying to navigate and integrate third party libraries, learning their APIs, keeping the dependencies updated. I'd encourage developers, especially Nodejs devs, to look at their list of dependencies and ask the following two questions about each of them: 1. How long would it take me to replicate this functionality? 2. How often does this functionality need updating? There is a threshold balanced between both of those questions where, once the numbers pass, it makes sense to bring in dependencies. But I truly believe the "instant gratification" primate part of our brains tends to overestimate the benefit of dependencies and underestimate the long term negatives of them. Here's a common Nodejs example: Request. Request is used all over many projects. Did anyone who imports it even try to use http.request in the nodejs stdlib? Its actually pretty great. Now, you introduced a new dependency. You made your build process longer. You made your deploy artifact bigger. You've got to keep it up to date. You've got to make sure there aren't security breaches. You've got to learn a new API that, unlike the Nodejs stdlib, is just made by "some guy somewhere" and is horribly documented inside a Github README. How long would it take me to replicate the functionality of request just using http.request? It depends what parts of request I'm using, but probably very little time. How often does this functionality change? Literally never. Literally never. HTTP/1.1 was finalized decades ago. Request, right now, has 48 open PRs, 560 open issues, was last "released" a couple months ago, and was fixing security issues which were definitely already fixed in stdlib. But the primate part of your brain says "Eh fuck all that, I'll let future self deal with the negatives of a new dependency, what I want today is an API interface that's, like, 20% easier to use." |