Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

Post reply on HN
Print view View original

211–220 of 412 posts

Re: The tragedy of running an old Node project

#211

Post by JansjoFromIkea »

jonathanlydall wrote: post #164
mvkel wrote: 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

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

I think there's much bigger deviations from long term stability the closer you get to a GUI as things deviate further from ideals into brute force hacks for stuff to look right.

Can remember trying to update a Unity project so it'd be still buildable for 64-bit Mac devices. The very first version bump I done resulted in several critical libraries no longer working and there being no clear alternatives to swap in.

Re: The tragedy of running an old Node project

#212

Post by RadiozRadioz »

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.

Re: The tragedy of running an old Node project

#213

Post by mleo »

cess11 wrote: post #199
ahoka wrote: post #165

Earlier quoted context omitted.

"Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem." We just had to workaround breaking changes in a patch version update of Spring Boot. Maybe it was true in 2005, but certainly not the case today. I know of products that are stuck in Java 1.8 and not because they are too lazy to upgrade.

I've been involved in bringing real old Java 1.4 and 6 and whatnot up to 17 and from classic app servers into cloud, can take a bit of work but it's pretty straightforward, mostly switching out deprecated methods to their successors and copying over boilerplate config from similar applications.

Depends on the frameworks in use. I have done the same as you in bringing code that was originally started on 1.4 up to 17 and now 21 and it just took grunt work, but not too crazy since most of it was bog standard Java.

However, some other projects around here using different application frameworks are stuck since the frameworks aren’t maintained or upgraded in ways that aren’t compatible anymore.

Looking into old Java code, it is hard to remember a time before enums and what a pain that is to deal with int constants instead of typed constants.

Re: The tragedy of running an old Node project

#214

Post by popcalc »

thrw42A8N wrote: post #195
fredrikholm wrote: post #168

Earlier quoted context omitted.

+1 on this. I've been using Go almost exclusively for the last 5 ish years partly because this sort of thing never happens.

You lucked into the period when they solved the issues. If you need to work with older projects and can't easily convert them, you're going to have a bad time.

I open up random Go projects from a decade+ ago every week with no issues.

Re: The tragedy of running an old Node project

#215

Post by popcalc »

Macha wrote: post #71
swatcoder wrote: post #47

Earlier quoted context omitted.

Why do you want your building materials to have a pulse? Ideally, in adopting dependencies, you should be looking for a mature utility whose design was clear and implementation is complete. If it's open source, you should be able to read and unserstand the code yourself, and you should make an earnest effort to do so, in case it has faults you wouldn't usually allow in your own code and in case you need to fork it at…

Something like a HTTP 1.1 client is something you might expect would be a pretty stable thing that doesn't need too many updates, right? But I would not assume that a HTTP client that has been untouched in 12 years supports SNI, for example, which means that actually it might be totally useless for a lot of modern sites (certainly Android did not support SNI 12 years ago).

You're going to put it behind nginx anyways, right? So why does it even matter?

Re: The tragedy of running an old Node project

#216

Post by c0balt »

wink wrote: post #152
arp242 wrote: 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.

I dug out a small Rust project from 2016 and with edition = 2018 I got it running again in under 30 minutes, I was kinda surprised. 8 years is ancient in terms of Rust. I have had more problems with certain other crates. But yeah, C/C++ usually don't really compare. 5 years is nothing, it should just work. For Go the big breaking moment was modules. All my pre - 2016?ish code would need some work.

Rust is kinda like c++ here, it's easy until you have a library that has external, non-vendored dependencies.

Re: The tragedy of running an old Node project

#217

Post by KronisLV »

ivan_gammel wrote: post #179
mvkel wrote: 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

I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me.

> I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes.

Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's another thing to update and fix.

I think the experience of code rot is universal and increases with the amount of dependencies you have.

Re: The tragedy of running an old Node project

#218

Post by Macha »

popcalc wrote: post #215
Macha wrote: post #71

Earlier quoted context omitted.

Something like a HTTP 1.1 client is something you might expect would be a pretty stable thing that doesn't need too many updates, right? But I would not assume that a HTTP client that has been untouched in 12 years supports SNI, for example, which means that actually it might be totally useless for a lot of modern sites (certainly Android did not support SNI 12 years ago).

You're going to put it behind nginx anyways, right? So why does it even matter?

Client, not server.

Re: The tragedy of running an old Node project

#220

Post by dmuth »

This is one reason why whenever I build a new project, I build it inside of a Docker container.

That way, the project has just the dependencies it needs, and I know I can rebuild it at some point in the future and will be unlikely to run into problems when I do.

Post reply on HN