Hacker News Reader

Comment by kreetx | Hacker News Reader

The article makes using dependencies look bad, while the actual issue rather is "quality controlling" the code in dependencies, as dead code elimination (or "tree shaking") removes the bloat from the final artifact. Because dependency as a concept itself is good, because going the opposite way and reinvent the wheel you'll get an even worse kind of bloat - bloat you have to maintain yourself.

View on HN

Nah, I disagree. Dependency as a concept is 100% neutral and contextual, and treating it as 100% positive is cause for several issues in software bloat, security and compatibility.

It’s like drugs: if a doctor prescribes, it’s probably ok. If you have an addiction, then you’re in for a lifetime of trouble.

If the dependency solves a thing you need and isn't part of your core business, it pretty much is 100% positive. E.g, do you really want to implement your own json parser? When will you then ship your actual product?

I'm answering to the claim that "dependency as a concept itself is good". They're not universally good, and have side effects even when they solve the problem at hand.

The answer to your questions is already in my reply.

I mean, deps aren't free.

You're buying them with the risk that they could become a threat in the future. At one point it's not worth it anymore.

Sure, nothing is, but where you draw the line? And why would you implement something again when you are unlikely to do it better, or even have time for it?

And of course, if you're doing just recreational coding to learn something, or if what you need differs from what is available, or the available thing seems sketchy somehow, then you'd write it yourself (if it's feasible). But for most things where what you need is clear and unambiguous, I don't see why you'd invent it yourself. For an established library it's unlikely that you'd do any better anyway.

(And again, if it's recreational what you are doing, you want to learn and have a hobby, of course, do it yourself. But in that case, you aren't actually looking for dependencies anyway - your goal is elsewhere.)

One should draw a different line depending on the situation. That's where the engineering comes in. There is no silver bullet. We should still be suspicious and judicious about every single dependency.

So with infinite resources it would be best to write everything from scratch?

This is not a black-or-white situation. There's no need to only go to one extreme or the other.

You have made your normative assessment very clear, but I haven't heard of where and how do you draw the line.

EDIT: Can't post any deeper, but the child can see that no such "statements" have been made.

Please re-read his or her replies. I will (re) state it explicitly if you don't see it, but I believe you will find it.

The explicit re-statement: There is no general line to draw of whether to use a dependency, or write code internally using a language's primitives (Or already-used libs); it varies based on the situation, and there is a high degree of subjectivity in each of these choices.

So what do you subjectively consider when making this choice?

Some examples:

  - How much work would it take to implement and maintain this if done without a library?
  - What other libraries are available?
  - Does this library meet our needs superficially, or will it be a robust solution long-term?
  - When our requirements change slightly, or we need to add or change features, will this library still work?
  - How much code architecture needs to change to integrate this? Does it require changing other parts of the program that it seems should not be required to change for the reason we are bringing this in?
  - What impact does including this have on binary size and compile time?
  - What is the risk of security vulnerabilities?
  - Does this library have its own deep dependency tree?
  - Will this require continuous maintenance to keep it in sync with other dependencies?
  - Does this library require certain system dependencies to be installed that will make the build more fragile / less portable?
  - Will using this dependency impact performance over implementing manually? (Or over another dependency)

A good dependency solves a well defined problem with a direct API towards it, so yes, if the dependencies you talk about aren't high quality then yes, don't use those.

Reply to the child

> So with infinite resources it would be best to write everything from scratch?

Re-read the parent and the other replies: A critical point you are missing is your interlocutor's practical mindset in contrast to your idealistic one. This is about making engineering-mindset tradeoffs; they vary depending on the specific scenario. The answer to your Reductio ad absurdum is yes, but I believe that side tracks rather than elucidates.

The current usage pattern means that you end up with multiple different JSON parsers linked into your product, multiple XML parsers, etc ...

The part you are missing: If something in the dependency isn't working as you'd like at some point later, making your code work as you desire may be dramatically more difficult than if you hadn't brought it in.

It isn't that hard to write a JSON parser (especially when it targets a specific application).

>do you really want to implement your own json parser?

On the recreational and creative side, maybe, but not as much as coming with an original exchange format which is a better feat to the specific case at hand.

On a professional side, if JSON support is a burden engraved in the specification so be it. Then having the transformation of the PL native data structure back and forth to various other formats shipped in the standard library is really the best that can hoped. As second best case it is having a single clearly preponderant and well maintained library. Otherwise, bet among a plethora of possible libraries is becoming less attractive compared to building something internally brewed.

Reply on news.ycombinator.com