Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never use a dependency that you could replace with an afternoon of programming

blog.carlmjohnson.net

Post reply on HN
Print view View original

321–330 of 333 posts

Re: Never use a dependency that you could replace with an afternoon of programming

#321

Post by 5Qn8mNbc2FNCiVV »

parliament32 wrote: post #314
VHRanger wrote: post #75

Earlier quoted context omitted.

Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one…

Everyone who's used NPM in production for a not-insignificant amount of time has realized just how bad nodejs dependency hell can be. Unfortunately, webdev-du-jour has decided pulling in a hundred npm packages is better than writing a few hundred lines of code. I keep hoping things like [1] are a joke but I'm starting to suspect they're not. [1] https://www.npmjs.com/package/is-odd

I'm sorry that my framework and bundler are using so many packages. Lemme just quickly install Android Studio and download a few gigabyte to develop and build my application. Ah yikes I'm on a different version, need to redownload now.

Re: Never use a dependency that you could replace with an afternoon of programming

#322

Post by 5Qn8mNbc2FNCiVV »

idreyn wrote: post #201

A year ago I needed a min-heap to build a priority queue at work. So first I grabbed 'heap' from npm (272k weekly downloads) and set it to work. But a few days later I realized my code was executing slower than expected because it sometimes needed to clone the data structure, and the clone instantiation would break the heap invariant in the array internals. It turned out there's been an issue open about this since ea…

This would be a perfect spot to solve those issues and make the packages better... Or y'know, publish your implementation and have it used by people with the same issue

Re: Never use a dependency that you could replace with an afternoon of programming

#324

Post by kova12 »

I would actually advise another way: if you have to waste the whole afternoon putting algorithm together, then it probably going to be a week after you implement all tests and fix all the bugs. But even if it was just afternoon, still not worth it. You don't want to maintain what you don't need to maintain

Re: Never use a dependency that you could replace with an afternoon of programming

#325

Post by misterpurple45 »

parliament32 wrote: post #314
VHRanger wrote: post #75

Earlier quoted context omitted.

Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one…

Everyone who's used NPM in production for a not-insignificant amount of time has realized just how bad nodejs dependency hell can be. Unfortunately, webdev-du-jour has decided pulling in a hundred npm packages is better than writing a few hundred lines of code. I keep hoping things like [1] are a joke but I'm starting to suspect they're not. [1] https://www.npmjs.com/package/is-odd

And the is-odd package.json requires is-number! Jesus...

Re: Never use a dependency that you could replace with an afternoon of programming

#326

Post by earthboundkid »

Shank wrote: post #253
nullc wrote: post #229

Earlier quoted context omitted.

> But now you know what the dependency is really supposed to do and why it's non-trivial, so you're in an even better position to evaluate which ones are good. I came in here to say this. If you think you're not qualified to write the function, you're probably also equally unqualified to choose someone else's implementation of it. There is a lot of stuff out there-- stuff which is widely used-- which is not fit for y…

Not a lot of people can correctly write cryptography code on the first try, but we definitely advocate for people pulling well known cryptography libraries and using them instead of building their own, for obvious reasons. Not many people are qualified to write a lot of things, but are capable of making sound dependency judgements with heuristics. The trick is to use good heuristics and to not use a library for every…

People keep bringing up crypto and I really have no idea why. Is there someone who believes they can write a crypto algo in an afternoon? If someone is that deluded, they aren't going to benefit from advice one way or the other.

Re: Never use a dependency that you could replace with an afternoon of programming

#328

Post by ezekg »

Typical programmer, wholeheartedly believing they can build a something in an afternoon and be done with it. I don't care how well you scoped the project -- it almost always takes longer. It's naive and all this does is cost businesses time and money. It's usually much more economical to go with a third-party than to build everything in-house, which needs to account for the costs of new-feature dev and long-term maintenance. I have an entire business running on that premise.

Re: Never use a dependency that you could replace with an afternoon of programming

#330

Post by parliament32 »

5Qn8mNbc2FNCiVV wrote: post #321
parliament32 wrote: post #314

Earlier quoted context omitted.

Everyone who's used NPM in production for a not-insignificant amount of time has realized just how bad nodejs dependency hell can be. Unfortunately, webdev-du-jour has decided pulling in a hundred npm packages is better than writing a few hundred lines of code. I keep hoping things like [1] are a joke but I'm starting to suspect they're not. [1] https://www.npmjs.com/package/is-odd

I'm sorry that my framework and bundler are using so many packages. Lemme just quickly install Android Studio and download a few gigabyte to develop and build my application. Ah yikes I'm on a different version, need to redownload now.

At least Android Studio doesn't break when you try to deploy it a few months down the line (with package lock), with the exact same version, because a dependency of a dependency of a dependency made an unreviewed and untested "security fix" that caused a regression.
Post reply on HN