Hacker News Reader

Comment by CivBase | Hacker News Reader

Devil's advocate here.

If you hadn't used those libraries, you would have had to implement functionality from those libraries in your own code. Presumably, your code would be subject to the same vulnerabilities and probably require even more work to update. After all, API changes are generally easier to handle than design changes.

</advocacy>

I do agree that tiny, insignificant libraries like "left-pad" are bad. Imo, a good dependency is one that significantly reduces the design complexity of a project.

View on HN

The problem is that you need one function and you're pulling an entire library. Also you have some limited use-case (e.g. you don't have to support IE 6), but libraries tend to accumulate all the cruft in the world over the years, so you're pulling and executing lots of unnecessary code. JavaScript is too dynamic to reliably delete unused code, so even approaches like tree shaking, etc do not work well. And left-pad style libraries has its own problems, yeah.

There are universal utility libraries. jQuery for DOM, underscore for general utilities. It's OK to use them, because everyone knows them. But if you miss some tiny function, just write it yourself. DRY principle often brings more harm than good.

I would argue whether DRY enforces 3rd party libraries usage. "Yourself" touches the code you wrote, noone asks you to use already written solutions.

For real, zero dependencies is as much an extreme view as infinite dependencies. There's something to be said about delegating some of the hard but ultimately not relevant problems to a library. I'm not about to roll my own datetime library or my own crypto library.

> I'm not about to roll my own datetime library or my own crypto library.

Same, but it's nice if those libraries have zero dependencies so when you include them in your project you know exactly what you're getting.

This. It's not that I want to avoid any dependency -- I'm more than happy to use a well-crafted library or tool that provides an abstraction that neatly covers a problem domain. But at some point the depth and complexity of the dependency tree can make it difficult for a package manager to keep in a correct state, which speaks to the opacity anyone who attempts to manually map it is going to end up confronting.

There are also bigger libraries like lodash that are often included for the use of a single feature.

I must admit I have the same aversion as OC. I love the ubiquity, resources and portability of JavaScript, but the rats nest of dependencies feels extremely brittle.

Not only is it often added for a single feature, that feature is more often than not already supported in vanilla JS or with ES 6.

Reply on news.ycombinator.com