Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

401–410 of 412 posts

Re: The tragedy of running an old Node project

#401
post #23

> 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

An anecdote — I recently upgraded an old NodeJS project written using v14 to 22. It used an old version of Svelte for the UI. It wasn’t too bad, took about 90 minutes to upgrade a bunch of Svelte 3 components to Svelte 5, with some assistance from Copilot.

This was with zero awareness of Svelte 5 (I only knew it was released — I wanted to upgrade because Node 14 is EOL now and I’d noticed some npm audit warnings.) So I feel I also learned something in the process.

Re: The tragedy of running an old Node project

#402
post #226

Earlier quoted context omitted.

I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. Then it turned out the standard built in GUI library I needed was no longer standard or built in. (I also used it ten years ago and it was a much better experience then.)

>I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. My son found a disk with some of my old java project from college 20 years ago and that's about what it took to run them, first figuring out how to even download java and then making some minor changes to get them running. I think we gave up trying to get the actual applet based on…

I know this is a late response, but for anyone curious you would need to use an official Oracle or Sun JDK/JRE from Java 8 or older. OpenJDK doesn't include support for applets.

You also need a browser that has NPAPI. IE 11 was the most modern browser I am aware of that still supported applets.

The old GUI framework mentioned in the GP might have been Swing. It is still included in most JDKs and allows for cross platform desktop GUI application development with no other dependencies outside the JDK. Finding documentation on how to do GUIs in Swing is getting increasingly difficult though.

Re: The tragedy of running an old Node project

#403

I call this phenomenon "node rot". Judging by the comments here, it seems like a universal experience. My favorite is the way that Python projects rot. Not only does Python's setuptools give you all the fun that node-gyp does, the common practice of versioning packages with packagename>=1.25.5 means you're almost guaranteed breakages as pip installs newer versions of packages than what the project was built with.

Oh, one of the worst forms of torture is definitely trying to get a random Python AI project from GitHub running locally. There's almost always a conflict between versions Python, Cuda, Pytorch, and a hodgepodge of pip and conda packages. Publishing a requirements.txt is the bare miminum everybody usually does, but that's usually not enough to reconstruct the environment. The ecosystem should just standardize to usin…

Don’t know if this would help your case or not, but jart’s llamafile seems like it would be useful

[6] https://github.com/Mozilla-Ocho/llamafile

Re: The tragedy of running an old Node project

#404
post #368

Earlier quoted context omitted.

> Two hours of work after 4 years sounds ... perfectly acceptable? It's really not. I'm in the same situation with a Go + React project I haven't really touched in 3 years. The Go part is just `go build`, it still works after 3 years and I have a build in a fraction of a second. The React project doesn't build anymore at all. I used Parcel 2 at the time, and it turns out it's incompatible with a Mac M1 for some reaso…

Go would be much worse than Node.js in most cases since dependencies directly reference GitHub projects which could have been deleted whereas NPM has a cache and immutability guarantee which makes old NPM modules available and unchanged.

You rely way less on dependencies when writing Go code though. That’s in big parts why it doesn’t break nearly as much (or at all).

Re: The tragedy of running an old Node project

#405
post #368

Earlier quoted context omitted.

> Two hours of work after 4 years sounds ... perfectly acceptable? It's really not. I'm in the same situation with a Go + React project I haven't really touched in 3 years. The Go part is just `go build`, it still works after 3 years and I have a build in a fraction of a second. The React project doesn't build anymore at all. I used Parcel 2 at the time, and it turns out it's incompatible with a Mac M1 for some reaso…

Go would be much worse than Node.js in most cases since dependencies directly reference GitHub projects which could have been deleted whereas NPM has a cache and immutability guarantee which makes old NPM modules available and unchanged.

Go also has the goproxy

Re: The tragedy of running an old Node project

#406
post #56

Earlier quoted context omitted.

Well, the "solution" ended up as "I gave up and just installed an old Node version and called it a day". So those 2 hours weren't even enough. I've been using Jekyll/Ruby since 2014 for my website, with a few custom plugins I wrote myself. And I've never really needed to do anything like this. It "just works". My Go and C programs are the same: "just works". I have some that are close to a decade old.

Good for you, my experience with Jekyll is closer to OP's experience with Node. I have a big website that I built in 2014, with tons of custom plugins, that is now stuck on Jekyll 2.x and Ruby 2.x, and has a ton of hidden C++ dependencies. The way I build it now is using a Dockerfile with Ubuntu 18.04. I probably could update it given enough effort, but I was rather thinking of rewriting it in Astro.js or Next.js.

Yes indeed, that is the solution to modern IT problems - never update your Ubuntu 18 containers and you're set.

(Wish I was joking, but sadly I'm serious.)

Re: The tragedy of running an old Node project

#408
post #131

Earlier quoted context omitted.

I think it was 'A Deepness In The Sky' that posited so many layers of legacy underlying the starship control systems of the era that one of the most crucial positions on a ship was that of 'Programmer-Archeologist.'

I am already a programmer archeologist, and it's one of the most rewarding parts of my job. Though my most recent project is regrettably well written and maintained. :)

im going to try and have this attitude

Re: The tragedy of running an old Node project

#409
post #402

Earlier quoted context omitted.

>I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. My son found a disk with some of my old java project from college 20 years ago and that's about what it took to run them, first figuring out how to even download java and then making some minor changes to get them running. I think we gave up trying to get the actual applet based on…

I know this is a late response, but for anyone curious you would need to use an official Oracle or Sun JDK/JRE from Java 8 or older. OpenJDK doesn't include support for applets. You also need a browser that has NPAPI. IE 11 was the most modern browser I am aware of that still supported applets. The old GUI framework mentioned in the GP might have been Swing. It is still included in most JDKs and allows for cross plat…

IIRC Oracle makes it really hard to find the download. Admittedly we didn't spend more than an hour or two messing around with all of it and getting the applets to run wasn't a high priority or anything.

Re: The tragedy of running an old Node project

#410
post #87

Earlier quoted context omitted.

Maybe they can try to get the node version into the package-lock tomorrow? This seems like an opportunity to improve the ecosystem, rather than a biting critique.

Or, instead of responding to sunk costs by getting sunk deeper into the muck, just cut your losses, ditch Node and its proprietary/non-standard APIs and unstable featureset, and use a standard runtime. The author of the blog post is trying to run a static site generator. A static site generator doesn't need to be able to do anything that Node provides that can't be done with the World Wide Wruntime (which they're alr…

[deleted]
Post reply on HN