2 ms·

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You ca

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate things twice a year." Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly. Most teams do neither, which is when projects rot fastest.

singpolyma3 5mo ago
Unless you just... Keep using the old version of the framework? No one is making you upgrade
- jonnyasmar 5mo ago
  You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.
- em-bee 5mo ago
  the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.
  - materielle 5mo ago
    Which brings us to the next layer of modern dependency management insanity: The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree. At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
- lmm 5mo ago
  Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.
  - singpolyma3 5mo ago
    Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.
    - lmm 5mo ago
      Yes and no. In practice sooner or later you need to update something - you need it to work with a new OS/database/TLS algorithm - and then often there's a domino effect.
mickael-kerjean 5mo ago
> even most of Go that way and your code will still run in 20 years While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499 ref: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash
killerstorm 5mo ago
The original Java standard class library is very capable, and you can do a lot using just 20+ years old classes. People responsible for Java platform design were thinking from perspective that software can be "done" and keep working for decades if not centuries. But modern Java developers don't want to write this way, it's not "modern". I guess incentives aka "job security" is the main force here. Would you rather say that a piece of software is "done" and can keep working for decades with only periodic maintenance required, or would you rather "we need to migrate from Quux to Baar as Quux is deprecated and unmaintained now, and Bazz might not be optimal from performance standpoint so we need a replacement. so yeah we'll be busy this year"? And conference people are so helpful with "Baar is the only valid way to make Java now. If you think about rawdogging JCL you're a goblin"

singpolyma3 5mo ago

Unless you just... Keep using the old version of the framework? No one is making you upgrade

jonnyasmar 5mo ago
You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.
em-bee 5mo ago
the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.
- materielle 5mo ago
  Which brings us to the next layer of modern dependency management insanity: The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree. At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
lmm 5mo ago
Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.
- singpolyma3 5mo ago
  Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.
  - lmm 5mo ago
    Yes and no. In practice sooner or later you need to update something - you need it to work with a new OS/database/TLS algorithm - and then often there's a domino effect.

mickael-kerjean 5mo ago

> even most of Go that way and your code will still run in 20 years While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499 ref: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash

killerstorm 5mo ago

The original Java standard class library is very capable, and you can do a lot using just 20+ years old classes. People responsible for Java platform design were thinking from perspective that software can be "done" and keep working for decades if not centuries. But modern Java developers don't want to write this way, it's not "modern". I guess incentives aka "job security" is the main force here. Would you rather say that a piece of software is "done" and can keep working for decades with only periodic maintenance required, or would you rather "we need to migrate from Quux to Baar as Quux is deprecated and unmaintained now, and Bazz might not be optimal from performance standpoint so we need a replacement. so yeah we'll be busy this year"? And conference people are so helpful with "Baar is the only valid way to make Java now. If you think about rawdogging JCL you're a goblin"