The fate of "small" open source

> 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/

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.

Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.

> since languages like Go never had this dependency hell

What is the feature of Go that this is referring to?

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

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.

Do you know that you can just add a small text file or a comment explaining that a module is vendored code. Ad updates is handled the same way as the rest of the code. And you will be “maintaining” it as long as you need to. Libraries are not “here be dragons” best left to adventurous ones.

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.

> 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.

It's a cultural thing.

And libraries try harder not to have absurd dependencies, than finished products (correctly, IMO).

Keyword: little.

Dependencies need to pull their own weight.

Shifting responsibilities is a risk that the value added needs to offset.

Copied text does not inject bitcoin mining malware three months after I paste it.

Most of these util libraries require basically no changes ever. The problem is the package maintainers getting hacked and malicious versions getting pushed out.

If you use an LLM to generate a function, it will never be updated.

So why not do the same thing with a dependency? Install it once and never update it (and therefore hacked and malicious versions can never arrive in your dependency tree).

You're a JS developer, right? That's the group who thinks a programmer's job includes constantly updating dependencies to the latest version constantly.

> If you're the author of a library, you have to cover every possible way in which your code might be used.

You don't actually. You write the library for how you use it, and you accept pull requests that extend it if you feel it has merit.

If you don't, people are free to fork it and pull in your improvements periodically. Or their fork gets more popular, and you get to swap in a library that is now better-maintained by the community.

As long as you pin your package, you're better off. Replicating code pretty quickly stops making sense.

Neither does a dependency you don't update, though, which is isomorphic to copied code you never update.

It's not NPM. It's JS culture. I've done a lot of time programming in TypeScript, and it never fails that in JS programmer circles they are constantly talking about updating all their packages, completely befuddled why I'd be using some multiple year old version of a library in production, etc.

Meanwhile Java goes the other way: twenty-year old packages that are serious blockers to improved readability. Running Java that doesn't even support Option (or Maybe or whatever it's called in Java).

It's a rare developer (or human for that matter) who can just shrug and say "fork off" when asked for help with their library.

> Install it once and never update it (and therefore hacked and malicious versions can never arrive in your dependency tree).

Huh? What if your once-off installation or vendoring IS a hacked an malicious version and you never realise and never update it. That's worse.

It would be healthy that it becomes more common, in fact the privately-owned public garden model of the Valetudo project [1] is the sanest way for FOSS maintainers to look at their projects.

[1]: https://github.com/Hypfer/Valetudo#valetudo-is-a-garden

Java writes to a bytecode spec that has failed to keep up with reality, to its detriment. Web development keeps up with an evolving spec pushed forward by compatibility with what users are actually using. This is "culture" only in the most distant, useless sense of the word. It is instead context, which welcomes it back into the world of just fucking developing software, no matter how grey-haired HN gets with rage while the world moves on.

EDIT: Obvious from the rest of your responses in this thread that this is trolling, leaving this up for posterity only

You're not a web developer, right? See my other comment about context if you want to learn more about the role of context in software development in general. If you keep repeating whatever point you're trying to make about some imaginary driving force to pointlessly update dependencies in web dev, you'll probably continue to embarrass yourself, but it's not hard to understand if you read about it instead of repeating the same drivel under every comment in this thread.

Hardly worth responding to, from other comments they're defending Java. They're not used to updates.

somehow, in the js/npm world, dependencies are updated willy nilly, which is the cause of a lot of that ecosystem's headaches.

It really depends. If it's the occasional request and I can bang out a solution in 30 minutes, I'll help. But I'll also weigh how much maintenance burden it'll be going forward. And if I won't do it myself, I'd always give some quick pointers.

Maintenance demands (your library X doesn't work with Python Y, please maintain another version for me) I'd shrug off. Wait for me, pay me, or fix it yourself.

Another thing about Go, and more generally, the statically-typed languages, is that these utility functions are generally safer to get a once-over and a commit into the code base than in dynamically-typed languages. Something that joins an array of strings with a joiner in some non-trivial way is a lot easier to review when you don't have to worry about it getting an array of DOM nodes and a NaN for the join character, and all the other things that could come in. Well-tested little utilities for Javascript are valuable, and I don't 100% trust LLMs to not give me code based on common misconceptions rather than the actually correct code in that case. Or at least, correct for some definition of correct, which in the dynamic languages can itself be some work to figure out.

Bad take. In the first place, the appropriate time order of magnitude for how long static type checkers have existed for JS is "decades". In the second place, the function that "joins an array of strings with a joiner" is the wrong place to worry about whether that array is actually an array of DOM nodes or the joiner is NaN.