Hacker News new | past | comments | ask | show | jobs | submit login

Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too.

But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.

I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.




I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.

For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:

1) Can't update react without updating react-router because react deprecated some API

2) Can't update react-router without updating react because the new version of react-router is using some new API from react

And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.

I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: