3 ms·

It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).

by thom 7y ago

Zelphyr 7y ago
That’s not limited to Clojure nor does it matter whether it’s a batteries included framework or not. I’m seeing this more and more, to the degree that often I’m back to rolling my own instead of relying on a library or framework that has a high likelihood to f being abandoned.
- freehunter 7y ago
  More and more I'm of the opinion that I don't want to use a library that's not included in the core product. I've had way too many dependencies become end-of-life before my application was EOL, and I ended up having to fundamentally change my application, putting in hours of work just to keep things the same, or rebuild a feature. I appreciate Rails for all the built-in stuff it provides but anything outside of that, as time goes on you're getting more and more likely to end support. Paperclip hit me hard, and my Rails apps are stuck on an unsupported library because it's not worth the time or effort to migrate to ActiveStorage. God help me if Devise is deprecated. That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years. I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.
  - Zelphyr 7y ago
    All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin. In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.
smnplk 7y ago
I get it, you want to be up to date all the time, but often the case is that lib is just done, it does what it says it does, so that is why lib was last updated x years ago.
- wokwokwok 7y ago
  Nonsense. This might have been true back in the day before security issues were a thing, but it no longer holds true. Particularly the case in public web apps. If someone isn’t maintaining it, don’t use it. (Obviously it depends; for a test framework, clearly not true, but for example for the “LEGO block” you pick for auth, or say, XML parsing... yes, it matters; the point here is specifically that the “take what you want” approach to a web framework results in scattered maintenance models for different components, and that is categorically bad for long term maintenance of a web app)
  - smnplk 7y ago
    Gibberish. If there is no activity on the repo it doesn't mean that someone is not maintaining it. Oh, like framework developers always know which LEGO block to include in their framework. Like Rails had no vulnerabilities in the past. > If someone isn’t maintaining it, don’t use it. Well, good luck with not using 3/4 (or even more) of software in existence. I bet the kernel that is running on your laptop depends on the software that hasn't been updated for 30 years.

It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).

by thom 7y ago

It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).

Zelphyr 7y ago

That’s not limited to Clojure nor does it matter whether it’s a batteries included framework or not. I’m seeing this more and more, to the degree that often I’m back to rolling my own instead of relying on a library or framework that has a high likelihood to f being abandoned.

freehunter 7y ago
More and more I'm of the opinion that I don't want to use a library that's not included in the core product. I've had way too many dependencies become end-of-life before my application was EOL, and I ended up having to fundamentally change my application, putting in hours of work just to keep things the same, or rebuild a feature. I appreciate Rails for all the built-in stuff it provides but anything outside of that, as time goes on you're getting more and more likely to end support. Paperclip hit me hard, and my Rails apps are stuck on an unsupported library because it's not worth the time or effort to migrate to ActiveStorage. God help me if Devise is deprecated. That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years. I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.
- Zelphyr 7y ago
  All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin. In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.

smnplk 7y ago

I get it, you want to be up to date all the time, but often the case is that lib is just done, it does what it says it does, so that is why lib was last updated x years ago.

wokwokwok 7y ago
Nonsense. This might have been true back in the day before security issues were a thing, but it no longer holds true. Particularly the case in public web apps. If someone isn’t maintaining it, don’t use it. (Obviously it depends; for a test framework, clearly not true, but for example for the “LEGO block” you pick for auth, or say, XML parsing... yes, it matters; the point here is specifically that the “take what you want” approach to a web framework results in scattered maintenance models for different components, and that is categorically bad for long term maintenance of a web app)
- smnplk 7y ago
  Gibberish. If there is no activity on the repo it doesn't mean that someone is not maintaining it. Oh, like framework developers always know which LEGO block to include in their framework. Like Rails had no vulnerabilities in the past. > If someone isn’t maintaining it, don’t use it. Well, good luck with not using 3/4 (or even more) of software in existence. I bet the kernel that is running on your laptop depends on the software that hasn't been updated for 30 years.