←back to thread

The tragedy of running an old Node project

(abdisalan.com)
272 points abdisalan | 1 comments | 18 Nov 24 18:24 UTC | HN request time: 0.001s | source
Show context
mvkel ◴[18 Nov 24 19:03 UTC] No.42175730[source]▶
> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

replies(21): >>42175799 #>>42175818 #>>42175826 #>>42175846 #>>42176217 #>>42176305 #>>42176788 #>>42176958 #>>42181497 #>>42182299 #>>42182564 #>>42182778 #>>42183020 #>>42183093 #>>42183501 #>>42183725 #>>42184814 #>>42192770 #>>42193606 #>>42194518 #>>42211558 #
fourseventy ◴[18 Nov 24 20:03 UTC] No.42176305[source]▶
Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...
replies(4): >>42176343 #>>42176528 #>>42185263 #>>42185292 #
Ameo ◴[18 Nov 24 20:24 UTC] No.42176528[source]▶
What ecosystem are you comparing to?

Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues.

Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.

Even Rust, which is usually great and has modern packaging and built-in dependency management, often has issues building old projects due to breaking changes to the compiler.

All this is to try to say that I don't think this is some problem unique to JS at all - but rather a side effect of complex interconnected systems that change often.

A big reason Docker and containers in general became so popular was because it makes this problem a lot less difficult by bundling much of the environment into the container, and Docker is very much agnostic to the language and ecosystem running inside it.

replies(6): >>42178164 #>>42179805 #>>42180587 #>>42181310 #>>42184179 #>>42191776 #
treflop ◴[19 Nov 24 06:36 UTC] No.42180587[source]▶
Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model.

I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time.

JavaScript has gotten better but it seems they are just re-learning things that were long figured out.

When I see new package managers, I just see a list of problems that they forgot to account for. Which I find strange when there have been many package managers that you can learn from. Why are you re-inventing the wheel?

replies(3): >>42182207 #>>42182685 #>>42183352 #
demosthanos ◴[19 Nov 24 13:46 UTC] No.42183352[source]▶
In JetBrains's Developer Ecosystem 2023 survey, 50% of developers were still regularly working in Java 8 [0]—the exact kind of "stick with the old version of the runtime" solution described in TFA.

[0] https://www.jetbrains.com/lp/devecosystem-2023/java/

replies(1): >>42183515 #
lucianbr ◴[19 Nov 24 14:02 UTC] No.42183515{3}[source]▶
Java 8 is 10 years old. If you had a project with a Java version that was recent 4 years ago (11 - 14), you could run it without any problems or changes.
replies(1): >>42183583 #
1. demosthanos ◴[19 Nov 24 14:08 UTC] No.42183583{4}[source]▶
Because they made the design choice to stop making large breaking changes to the language and tooling. Java 8 to 9 wasn't easier than Java 8 to 17 is, it's getting off of Java 8 that is hard because they made the choice to break so much in 9.

Node does not promise indefinite backwards compatibility, which is a design choice that they've made that allows them to shed old baggage, the same way that the Java developers chose to shed baggage in 8->9. Neither choice is inherently better, but you do have to understand which choice a language's designers were making during the time window in question when you go to run it later.