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

Cull your dependencies

tomrenner.com

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Cull your dependencies

#51

Post by azangru »

quickthrower2 wrote: post #5

It is a fine balance. Good luck doing that in JS which has zero standard library on the browser. C#, for example is in better shape and you can do a lot before you reach for nuget for anything outside of Microsoft. I prefer to not import tiny libraries but adopt the code into the codebase.

> JS which has zero standard library on the browser.

Could you explain what you mean by a standard library or by zero? :-) Or, more to the point, what are the specific things that you would add to JS standard library that you find missing in the browser?

Consider the latest release of an evergreen browser as a reference point.

(I know about date manipulations. This should be addressed by the Temporal proposal that's already at stage 3. What else?)

Re: Cull your dependencies

#52

Post by pornel »

eatonphil wrote: post #8
quickthrower2 wrote: post #5

It is a fine balance. Good luck doing that in JS which has zero standard library on the browser. C#, for example is in better shape and you can do a lot before you reach for nuget for anything outside of Microsoft. I prefer to not import tiny libraries but adopt the code into the codebase.

> Good luck doing that in JS which has zero standard library on the browser. The article is saying something more like vendor your dependencies (and cut out the stuff you don't use within dependencies). > I prefer to not import tiny libraries but adopt the code into the codebase. Yep that's what the article is saying.

I don't get why people find vendoring valuable. If you vendored log4j, you'd get the same exact bug in your vendored version, and you'd need more work to pull in the fix.

Perhaps people imagine that if they vendor they'll review all the code they pull in, but I've never seen it happen in practice beyond "LGTM". It wouldn't have found the log4j vulnerability, and could overlook even intentionally malicious code if only the source looked innocent-enough at the first glance.

Re: Cull your dependencies

#53

Post by fmajid »

smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

And it will cost vital time to market. I am very conservative about introducing dependencies but there is a reason why they are proliferating and it is not just developer laziness.

Here’s a very good take from Joel Spolsky:

https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

Not everyone has the resources of a Microsoft, though.

Re: Cull your dependencies

#54

Post by jvanderbot »

Applying a blanket rule like this is always wrong. It makes sense in prototyping to have a good mix of pull-vs-make. Make the small things that are easy to do, and pull the things that make you more productive, even if they are huge.

Maybe during maturation, each dependency should be "vendorized" as much as possible. Fork it, find an internal maintainer. I suspect that very quickly nobody will want to pull in a lot of dependencies any more, and miraculously a much smaller, much more specifically-suited codebase will appear to solve the very small subset of problems you actually need to solve right now (rather than all problems the dependency could solve).

But ultimately: "If it’s a core business function — do it yourself, no matter what."

Re: Cull your dependencies

#55

Post by marcosdumay »

smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

> It's a balanced choice but the stakeholders are not prepared to invest more.

Well, that's not how "balanced" looks like.

Anyway, a lot of quality-driven activities pay out well within the initial development of a project, on what case, it's not a balanced choice anymore, it's a complete no-brainier. Still, I'm yet to see money-oriented stakeholders accepting those.

Re: Cull your dependencies

#56

Post by a15971 »

smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

It's not that '... developers ... are lazy, and prefer to write as few lines of code as possible, sticking rigidly to the principle of "not reinventing the wheel"'.

They don't do that because they are lazy. They do that because of competitive pressure. In SW development, in most cases, particularly in enterprise development, "the fastest person wins". Whoever moves fast and delivers fast will get to do more projects and have more influence over direction of projects. "Not reinventing the wheel" is of course in vast majority of cases faster than reinventing it.

Because in most cases it's not important to write the best possible code, it's to write "good enough" code, on time and on budget. Insecure code is of course not "good enough", so competitive pressures will adjust accordingly.

Re: Cull your dependencies

#57

Post by jonnycomputer »

Having been burned early having to support an application with rotting dependencies, I tend to feel this. In my Python applications, I make an effort to use the standard library solutions over third-party ones whenever possible, even when they might not have all the features I want. There are however occasions when I must use third party dependencies, and some of them give me hell (e.g. dependencies that refused to install with a simple 'pip install X')

Re: Cull your dependencies

#58

Post by marginalia_nu »

MrJohz wrote: post #47
marginalia_nu wrote: post #21

Earlier quoted context omitted.

System.out.println, or some thin wrapper there-around. Most of what log4j does is stuff that arguably should be done outside of the application, such as log rotation and piping to file and what have you.

I mean, dependencies outside of your application are still dependencies. I trust, say, systemd somewhat more than I trust log4j (although both would very much be in my "broadly trustworthy" category), but a few years back there was the shellshock vulnerability, so it's not like system components are somehow immune here.

The difference with external dependencies is that they are in a sense independent from your code. The real devastating aspect with log4shell is that log4j couples and integrates itself with deployed code.

You can't just upgrade log4j without pushing a new release of your applications in the way you can say roll out an updated nginx or logrotate or kibana or whatever.

Re: Cull your dependencies

#60

Post by jeroenhd »

quickthrower2 wrote: post #5

It is a fine balance. Good luck doing that in JS which has zero standard library on the browser. C#, for example is in better shape and you can do a lot before you reach for nuget for anything outside of Microsoft. I prefer to not import tiny libraries but adopt the code into the codebase.

The browser has one of the most extensive standard libraries out there.
Post reply on HN