The tragedy of running an old Node project

Original Article ↗ Hacker News Discussion ↗

Running a four‑year‑old Node.js project can mean hours of wrestling with broken dependencies, native build tools like node‑gyp, and incompatible runtime versions, even for something as simple as a static site generator. Commenters contrast this fragility with ecosystems such as Go, Java, Perl, or even plain browser JavaScript, where decade‑old code often still compiles and runs. Many argue the root causes are cultural—rapid churn, deep transitive dependency trees, and native extensions—while proposing mitigations like strict version pinning, containers or Nix for reproducible environments, avoiding native addons, and preferring simpler, “buildless” stacks for long‑lived projects.

Fragility of Older Node Projects

  • Many commenters report that Node projects “rot” quickly: even a few months’ or years’ gap can make them hard or impossible to build.
  • Breakage often appears when trying to run old code on a newer Node version, or when dependencies have silently changed or vanished.
  • Some argue two hours of work after four years is acceptable; others say that in other stacks they routinely revive 10–20‑year‑old code in minutes.

Native Extensions and node-gyp

  • node-gyp and native addons (C/C++ bindings) are repeatedly cited as the main source of pain: toolchains change, Python 2 vs 3 issues, missing system libs, architecture mismatches.
  • Advice: avoid packages that depend on node-gyp unless absolutely necessary (e.g., password hashing, image processing). Prefer pure JS, or offload such concerns to external services.

Comparisons with Other Ecosystems

  • Several ecosystems are described as more stable for old projects: Go, Java, C/C++, C#, Perl, PHP, Common Lisp, R, Tcl; others (Python, Ruby, Android, React Native) are reported to have similar or worse bitrot.
  • Some note that problems correlate strongly with deep transitive dependency trees and native extensions, not just language choice.
  • Debate exists: some say Go/Java/C# “just work” for decade‑old code; others recount hard upgrades (Java 8→9, Spring, Gradle, Xamarin, old Go without modules).

Dependency & Environment Management Tactics

  • Recommended practices:
    • Pin Node version (engines in package.json, .nvmrc, asdf/mise, devShells).
    • Commit lockfiles and, when possible, vendor dependencies.
    • Use Docker or similar to freeze OS, toolchain, and Node version.
    • Run CI to ensure builds stay reproducible.
  • Lockfiles and narrow version ranges improve reproducibility but can over‑constrain environments; some argue for libraries that support wider version ranges.

Cultural and Architectural Critiques

  • Several see Node/npm issues as cultural: speed and churn, huge dependency graphs, frequent framework rewrites, loose attitudes about stability and semver.
  • Others stress this is a general modern‑software problem: maintainers lack incentives to support old versions, and any stack with many moving parts will decay.

Alternatives and Mitigations

  • Suggestions include:
    • Buildless or low‑tooling approaches (vanilla JS, HTMX, Alpine, simple static site generators, Hugo).
    • Choosing ecosystems with strong backward compatibility and big standard libraries.
    • Keeping dependencies minimal and treating them like own code.