> We should always try to strive to lower dependencies when it makes sense.
Maybe, but I think 'when it makes sense', might be 'rarely'. There a 2 ways to avoid dependencies: 1. lean on a batteries-included standard lib as this gist does or 2. write it yourself.
Problem with 1. is standard lib libraries aren't always great, see 'where modules go to die' [1],
(examples: httplib/urllib in Python, or the string libraries in PHP). This can stifle innovation and alternatives, unless an alternative with a strong marketing push can arise ('requests' for Python). Sadly, often because the situation isn't 'that bad' (as in the case of PHP) people continue to use poor APIs.
Problem with 2. is you're probably getting an order-of-magnitude fewer brain cycles on code you wrote yourself -- unless you can spend the extra effort to open-source it, and get lucky with popularity/contributors, it's likely to be inferior than a well-maintained 3rd party alternative.
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."
This is what I love about Go, and why I moved away from Node. The culture of fewer dependencies.
I only use the stldlib in Go, and a few packages (like google/uuid) that will become part of the stdlib at some point.
I know exactly what my program is doing, and why.
In Node, I would often hit 100+ dependencies before getting to the actual meat of the thing, and if there was a problem I had no idea where to look in the mess of other people's code. Given the number of PR's on the average node module, and the number of dependencies, I was guaranteed to be importing bugs every time I used an external module. Whether I hit one of those bugs and had to deal with it was a matter of luck. Dealing with bugs in someone else's library is a million times worse than writing the code myself.
If you are using Go to create something, then just use the built in webserver library (as shown in this repo). So that would make this project as a library (not just as an exercise / protoype) useless. Don't you think?
We should always try to strive to lower dependencies when it makes sense.