Comment by Aperocky
8 hours ago
> the era of small, low-value libraries like blob-util is over.
Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell.
npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad".
Instead of writing endless utilities for other project to re-use, write actual working things instead - that's where the value/fun is.
But as Go puts it:
“A little copying is better than a little dependency.”
https://go-proverbs.github.io/
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
> you just have to do maintenance through manual find-and-replace now
Do you? It doesn't seem even remotely like an apples-to-apples comparison to me.
If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your library (possibly causing more bugs) to accommodate, etc.
If you instead imaging the same functionality being just another private thing within your application, you only need to make sure that functionality works in the one single way you're using it. You don't have to make it arbitrarily general purpose. You can do error handling elsewhere in your app. You can test it only against the range of inputs you've already ensured are the case in your app, etc. The amount of "maintenance" is tiny by comparison to what a library maintainer would have to be doing.
It seems obvious to me that "maintenance" means a much more limited thing when talking about some functionality that the rest of your app is using (and which you can test against the way you're using it), versus a public library that everyone is using and needs to work for everyone's usage of it.
3 replies →
Copied text does not inject bitcoin mining malware three months after I paste it.
1 reply →
Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.
2 replies →
Most of these util libraries require basically no changes ever. The problem is the package maintainers getting hacked and malicious versions getting pushed out.
4 replies →
Keyword: little.
Dependencies need to pull their own weight.
Shifting responsibilities is a risk that the value added needs to offset.
Yeah it's the main thing I really dislike about this - how do you make sure you know where it's from? (ie licensing) What if there are updates you need? Are you going to maintain it forever?
For some definition of "small piece of code" that may be ok, but also sometimes this is more than folks consider
1 reply →
If I vendor a dependency that currently works for what my program does, I only have to care about it again if a security hole is discovered in it or if my program changes and the dependency is insufficient in some way. I don't have to worry about the person I'm importing code from going weird or introducing a bug that affects me.
Yep something like blob util could be a blog post or a gist (or several stack overflow answers). And a lot of NPM library falls under that. They always have the anemic standard library of JavaScript forgetting that the C library is even smaller.
> since languages like Go never had this dependency hell
What is the feature of Go that this is referring to?
It's a cultural thing.
And libraries try harder not to have absurd dependencies, than finished products (correctly, IMO).