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.

▲

abdisalan a year ago | parent | next [-]

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?

▲

swatcoder a year ago | parent | next [-]

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

▲

Macha a year ago | parent [-]

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

▲

popcalc a year ago | parent [-]

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

	▲	Macha a year ago \| parent [-]
		Client, not server.

▲

toast0 a year ago | parent | prev | next [-]

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.

▲

cousin_it a year ago | parent | prev [-]

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

▲

a year ago | parent | prev | next [-]

[deleted]

▲

kaptainscarlet a year ago | parent | prev [-]

Node is bad but the worst I have seen is Android

▲

telgareith a year ago | parent [-]

How about node on android?

▲

lpapez a year ago | parent [-]

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

▲

ian-g a year ago | parent [-]

Too late, we already have react native

	▲	kaptainscarlet a year ago \| parent \| next [-]
		It's a double whammy
	▲	plaidphantom a year ago \| parent \| prev [-]
		And Nativescript.