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.

▲

mickael-kerjean an hour ago | parent | next [-]

> 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

▲

singpolyma3 3 hours ago | parent | prev [-]

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

▲

jonnyasmar 3 hours ago | parent | next [-]

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 2 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		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.