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

161–170 of 412 posts

Re: The tragedy of running an old Node project

#161

Post by DecoySalamander »

watt wrote: post #157
ramesh31 wrote: post #22

Earlier quoted context omitted.

>Really wonder how that wart became such a critical tool used by so many packages. The original dream for Node was that it would simply be a glue wrapper around libuv that allowed for easy packaging/sharing of modules written in C++. But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native. Ryan Dahl stated this was indeed his biggest mistake/regret with Node,…

What is the Deno solution though? (I assume it's not sharing modules written in C++?)

Deno's solution is coming out years later when JS is fast enough that there is no need to involve C++ for most applications.

Re: The tragedy of running an old Node project

#162

Post by wink »

getcrunk wrote: post #8
abdisalan wrote: post #5

Earlier quoted context omitted.

Hold on, you had to do binary surgery using an OpenSSL version from an old box you had? I salute the dedication.

How exactly does one do that. Sounds exciting!

Not the OP but what sometimes works is as easy as:

``` ldd your-binary ``` on the old host and then copy all the thing that is referenced, put into ./foo and then start like so on new host: `LD_LIBRARY_PATH=./foo ./your-binary`. (may include typos, from memory)

A great tool for this used to be https://github.com/intoli/exodus - not sure if it still works.

Disclaimer: Also please don't do this with network-facing services, security applies, etc.pp. but it's a good trick to know.

Re: The tragedy of running an old Node project

#163

Post by segfaltnh »

Aeolun wrote: post #129
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.

Every single time I clone anything Go, I first spend a few hours sorting out dependency issues.

This shocks me, what sort of issues do you hit?

Re: The tragedy of running an old Node project

#164

Post by jonathanlydall »

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.

Re: The tragedy of running an old Node project

#165

Post by ahoka »

treflop wrote: post #114
Ameo wrote: post #75

Earlier quoted context omitted.

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.…

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 o…

"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.

Re: The tragedy of running an old Node project

#166

Post by nikanj »

uludag wrote: post #14

The worst part isn't just that it's nearly impossible to run/update an outdated JS project, but that this process will repeat itself ad infinitum. On the flip side, anything that uses vanilla JS without a build will most likely run just fine, probably till the end of human civilization.

Or until Google decides to change things to be more standards compliant, regardless of the collateral damage

Re: The tragedy of running an old Node project

#167

Post by blenderob »

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

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

Pefectly acceptable? Perfectly? Really? I have 10 year old C and Go projects that build and run fine as if nothing has changed. I can upgrade the dependencies if I want to but that's on me. The projects themselves have no problem building and running fine.

Re: The tragedy of running an old Node project

#168

Post by fredrikholm »

segfaltnh wrote: post #163
Aeolun wrote: post #129

Earlier quoted context omitted.

Every single time I clone anything Go, I first spend a few hours sorting out dependency issues.

This shocks me, what sort of issues do you hit?

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

Re: The tragedy of running an old Node project

#169

Post by rkharsan64 »

lvturner wrote: post #119
baq wrote: post #96

Earlier quoted context omitted.

...until the node version you locked can't be downloaded anymore, or hasn't ever existed for your CPU arch.

I see you too had to run node v14(? my memory fails me somewhat) on Apple Silicon hardware...

FWIW, I run Node 12 painlessly on Apple Silicon using fnm, so you might be thinking of a few versions before that.

Re: The tragedy of running an old Node project

#170

Post by cies »

skeletal88 wrote: post #125
Ameo wrote: post #75

Earlier quoted context omitted.

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.…

Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages. Python has a very rich standard library. You can do a lot with libc, if you had a c++ Qt project then it would provide you with basically everything you could ever need.

> Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages

That's not the only reason. :)

Horrible syntax full of inconsistencies, bolted on type system with TypeScript helps but will always be bolted on, quirks everywhere, as if `null` was not bad enough they also have `undefined`, I can go on.

I simply avoid it for anything but small enhancements scripts on otherwise static HTML pages.

Post reply on HN