[dozzie]

This is why developers should try to avoid introducing dependencies. Not at all costs, of course, but typical project in JavaScript, Go, Ruby, or Python has way, way too many dependencies, while little of them have any significant benefit.

[msutherl]

What's the downside? I think it's great. More modularity + distributed responsibility = better.

[dozzie]

Delegating things to a library you give up control over any bugs the library has. You can't simply fix the bug like you would do to your code, you either need to fork the library (maintaining a fork has cost), patch it (maintaining the patch is not free), or send fixes to its maintainer -- or any combination of these.

Using many dependencies also makes your application a fractal of dependencies. Library you use has its own dependencies, which have their own dependencies, which have... And so on. If you happen to want to put your application to DEB/RPM packages properly, host your app's dependencies locally to isolate from network outages, or do virtually anything non-trivial with your app, you hit the list of dependencies very hard.

It's not to say dependencies are evil; like any generalization, this would be simply stupid. But they have their cost, and it's large. You'd better make sure a library really simplifies your life before adding it to your project.

[tracker1]

And writing custom code to duplicate a library doesn't have a cost? (compared to forking).

I find that using tools like npm, nuget, gems, and the like along with github for core libraries makes managing dependencies FAR better than relying on an internal copy of said package in my project, which is just as risky as an internal fork. Yes, there's a chance the package system can be down while you are wanting to deploy.. that's why you prepare on a staging server, and duplicate that to production. Hell with things like docker, you create your container, and run it with environment variables for which environment it's running against.

[dozzie]

> And writing custom code to duplicate a library doesn't have a cost? (compared to forking).

Of course it does, but again: it's you who controls the code, not the library's upstream. You can easily patch and adjust whatever necessary, without being bothered with future merges from upstream.

This aspect grows in importance as the library gives less and less benefits. For example, I wouldn't hesitate to use Flask or Django for a web application, but I would think very hard what good is going to give me logging library other than Python's built-in.

> I find that using tools like npm, nuget, gems, and the like along with github for core libraries makes managing dependencies FAR better than relying on an internal copy of said package in my project

npm and gems give you dynamics very different from seeing dependencies by yourself. You see dependencies as very cheap (which is not true, it's just the cost is hidden from you), so you don't bother with thinking if you really need the new dependency. If it can shorten your code by twenty lines, you see it worth.