A counter-example I've noticed to the instinct of gravitating towards tools with huge amounts of ongoing activity is with Clojure and Common Lisp libraries. A lot of the times these will simply be "done" - there are libraries getting used regularly today that haven't seen a single commit in years because they cover all use cases as expected already. It's a little weird to go to a useful library's repo and notice it looks "dead" for all intents and purposes, when really it's just a completed solution. With JS framework churn taking so much mindshare and generating so many headlines it can feel like software that's only a few years old is already horrendously out of date, but this couldn't be further from the truth.
Agreed. I find that as projects mature the drive to add bloat or the desire to 'cover every use case as a first class use case' is detrimental to the library, the language, and the community. Projects can be 'done' just like any physical project.
This reminded me of a blog post I read recently about The Source History of Cat Linux command. The first version was written in the late sixties and the current version has not changed in years. Yet, it remains useful year after year.
There is a lot to be said for projects that actually achieve "done". A lot of projects will keep adding features and bloat so that it diverges from its original goal, and others will just be abandoned in a buggy state. But a project that's actually "complete" is really hard to achieve and is a sign of a well-made and high-quality library.
As an example, I recently adopted thumbnailator for basic image manipulation in Java, even though it hasn't received an update in years. But every indication I found shows that the product is fully mature and complete, even with the author stating that he is not accepting PRs anymore! And I have no heartburn about adopting this "older" technology at all.
Yeah, this is a really great point. A lot of the JS struggles have to do with how tightly they couple to the browser or whatever platform they run on, which will change out from under them.
This is a good point, but I think "done" is a state of minor change as opposed to no change. Dependencies will always update and break, vulns will pop up, etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A counter-example I've noticed to the instinct of gravitating towards tools with huge amounts of ongoing activity is with Clojure and Common Lisp libraries. A lot of the times these will simply be "done" - there are libraries getting used regularly today that haven't seen a single commit in years because they cover all use cases as expected already. It's a little weird to go to a useful library's repo and notice it looks "dead" for all intents and purposes, when really it's just a completed solution. With JS framework churn taking so much mindshare and generating so many headlines it can feel like software that's only a few years old is already horrendously out of date, but this couldn't be further from the truth.
Agreed. I find that as projects mature the drive to add bloat or the desire to 'cover every use case as a first class use case' is detrimental to the library, the language, and the community. Projects can be 'done' just like any physical project.
This reminded me of a blog post I read recently about The Source History of Cat Linux command. The first version was written in the late sixties and the current version has not changed in years. Yet, it remains useful year after year.
There is a lot to be said for projects that actually achieve "done". A lot of projects will keep adding features and bloat so that it diverges from its original goal, and others will just be abandoned in a buggy state. But a project that's actually "complete" is really hard to achieve and is a sign of a well-made and high-quality library.
As an example, I recently adopted thumbnailator for basic image manipulation in Java, even though it hasn't received an update in years. But every indication I found shows that the product is fully mature and complete, even with the author stating that he is not accepting PRs anymore! And I have no heartburn about adopting this "older" technology at all.
Agreed. Consider:
and
Yeah, this is a really great point. A lot of the JS struggles have to do with how tightly they couple to the browser or whatever platform they run on, which will change out from under them.
True enough - being a hosted language means there's a nice clean buffer between the dev and the platform
This is a good point, but I think "done" is a state of minor change as opposed to no change. Dependencies will always update and break, vulns will pop up, etc.