One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa.

It's OK. Not every language ecosystem is so busted that you can reliably expect a project not to work if someone isn't staring at it weekly and building it over and over again just in case. Now, it's always a risk, sure, no language anywhere is immune to the issue [1], but there's plenty of languages where you can encounter things from 5 years ago and your default presumption is that it's probably still working as well now as it did then. It may be wrong, but it's an OK default presumption.

[1]: Well... no language in common use anyhow. There's some really fringe stuff that uses what is basically content-based references for code dependencies, but I'm not aware of anything that I'd call "production quality" that even remotely looks like that, and is immune to someone just plain making an error with the semantic versioning or whatever.

> frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks

Lol, my perspective is almost the opposite. If it's got a lot of commits in the last six weeks, I need to look for something that's stable. Unless there's a good reason for so many commits; I feel like that many commits means it's in active development, which implies the requirements and interfaces aren't yet determined and who wants to rely on that?

These JS developers would probably shiver at seeing many Common Lisp repos with a last commit like 12 years ago and still working like a charm.

I’m curious, how do you measure the pulse of a project that old? Do people still talk about it? Or that not even necessary — use it until it breaks and otherwise don’t think about it?

Why do you want your building materials to have a pulse?

Ideally, in adopting dependencies, you should be looking for a mature utility whose design was clear and implementation is complete.

If it's open source, you should be able to read and unserstand the code yourself, and you should make an earnest effort to do so, in case it has faults you wouldn't usually allow in your own code and in case you need to fork it at some point.

This lets you you build well-designed, stable, maintainable, clear things yourself.

The alternate, building your project on a random collection of "living" projects undergoing active development is how you banish yourself to perpetual maintenance, build failures and CVE warnings that have nothing to do with your work, surprise regressions when you update your referenced version (you are, at least, pinning your versions??), etc

Something like a HTTP 1.1 client is something you might expect would be a pretty stable thing that doesn't need too many updates, right?

But I would not assume that a HTTP client that has been untouched in 12 years supports SNI, for example, which means that actually it might be totally useless for a lot of modern sites (certainly Android did not support SNI 12 years ago).

You're going to put it behind nginx anyways, right? So why does it even matter?

Client, not server.

If it has an issue tracker, you can look in there for things that look like real issues and are unaddressed.

If there's no issue tracker, you can YOLO and try it and see if it works, or you can look around at the code and see if it looks reasonable.

Even if there are unaddressed issues, you can always use it and fix it when it breaks. If it's reasonable enough, it's a good start anyway. And at least my assumption with open source is I'm going to be fixing it when it breaks, so lack of a pulse is better than churn.

Maybe "pulse" could be transitive? Like, if a project doesn't have many recent commits, but many projects using it have recent commits.

Node is bad but the worst I have seen is Android

How about node on android?

Delete this comment right now, don't give them ideas.

Too late, we already have react native

It's a double whammy

And Nativescript.

I would expect most Java projects from 20 years ago to compile and run with zero issues.

Absolutely not. Not on the client side anyway.

I know of one application by a large multinational that requires java in the browser to run. Almost impossible to run now because of security restrictions.

well java on the desktop and java in the browser are two entirely different beasts. the problem here is not java but the changes that have been made in the browser.

We do have some very old and likely lost all sources "client apps" that are a single JAR and date from around 2003-2004, written in Swing. They still work.

Of course when they stop working they will be phased out, but we have been expecting their death for years now and not happening yet.

The ecosystem has not improved since then.

Wow, that’s honestly impressive.

If there was an option to guarantee versions could exist for X amount of years (maybe even months?) then that would greatly help the stability of projects.

the problem was your research before using the packages then. So much bad engineering and architectural planning is blamed on the tools, not the human using it.