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

I don't agree with this at all.

While it's true that there are lots of bad libraries and many libraries are easy, you really isolate yourself from the broader ecosystem by doing this. Vendors and 3rd party solutions are now much harder to use, and when you use them you'll probably only use them at a surface level instead of using all the features.

And some things are so mature and vast you don't have a chance of building them yourself. If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work.




> If what you are doing can be done well in very mature ecosystems like React or PyTorch, the effort to recreate them will dwarf the time spend on important work.

Sometimes that's effort that's not really necessary. At work we had a team build a dashboard with React and a few graphs recently. It clocks at 2000 unique dependencies. That's not a typo, it's two thousands dependencies for a few graphs. Reimplementing all of that would take many man-years of work, but I think it wouldn't be necessary in the first place. Chart.js doesn't use any runtime dependencies, and could probably fill most of our needs. Chart.js is 50k of Javascript, which is a lot but probably more than we need. I don't know how much time it would take to make a reimplementation to have the API we need, but I think it's doable. Why would we want to do that? Because those 2000 dependencies are a liability. Last time I checked 165 were looking for funding. It would be easy to imagine a malicious actor paying a few people to contribute to low profile but widely used JS libraries, and take over the maintenance when the original maintainer becomes tired. I don't know if this is a worse liability than developing our own chart library. I don't know much about security and the tradeoff involved.

All of that to say, isolation from the broader ecosystem may be a good thing.


I guess you mean 2000 dev dependencies because for production that would be crazy.


I'll have to check but at least half of those are for production.


I know plenty of companies not using third parties for security or ideological reasons.

Code is code: both models (3rd party vs no 3rd party) can work and the time spent reinventing the wheel is not necessarily business breaking.




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

Search: