3 ms·
The article makes using dependencies look bad, while the actual issue rather is "quality controlling" the code in dependencies, as dead code elimination (or "tr
by kreetx 1y ago
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.
- whstl 1y agoNah, 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.
- kreetx 1y agoIf 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?
- whstl 1y agoI'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.
- k__ 1y agoI 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.
- kreetx 1y agoSure, 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.)
- whstl 1y agoOne 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.
- kreetx 1y agoSo with infinite resources it would be best to write everything from scratch?
- whstl 1y agoThis is not a black-or-white situation. There's no need to only go to one extreme or the other.
- kreetx 1y agoYou 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.
- the__alchemist 1y ago
- rjsw 1y agoThe current usage pattern means that you end up with multiple different JSON parsers linked into your product, multiple XML parsers, etc ...
- the__alchemist 1y agoThe 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.
- kovac 1y agoIt isn't that hard to write a JSON parser (especially when it targets a specific application).
- psychoslave 1y ago>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.