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

391–400 of 412 posts

Re: The tragedy of running an old Node project

#391

Post by __MatrixMan__ »

kiru_io wrote: post #377
__MatrixMan__ wrote: post #210

> Two hours of my life gone, just to pick up where I left off. If I had only wasted two hours every time I had to use npm for some reason I'd be significantly ahead of where I am now.

Doesn't that apply to any it-issues you don't know how to solve?

no, most of the time when a README says:

> run command xyz

I run xyz and I'm on to the next step in an average of ten or fifteen minutes (because yeah, stuff still goes wrong some times).

But if the instruction is to invoke npm, there's always some crazy side quest involved. It doesn't get any better with time because next time around it's a totally different side quest. I can't even offer any criticism towards fixing it, it just sucks for unique new reason every time.

Re: The tragedy of running an old Node project

#392

Post by incrudible »

vivzkestrel wrote: post #384
itsjzt wrote: post #373

Earlier quoted context omitted.

Use bcryptjs https://www.npmjs.com/package/bcryptjs

i did mention "and while pure js alternatives are available, they run terribly"

Slow is much faster than it not working at all. If this is a project that you might not touch for months or years, perhaps having fast bcrypt is not that important.

Re: The tragedy of running an old Node project

#393

Post by __MatrixMan__ »

lexlambda wrote: post #271
RadiozRadioz wrote: post #212

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.

And project specifying "requires python 3.X+" instead of Version X to Y is also a major culprit I often encounter. Most of the times it will not work with the newest shiny python, which I only notice after already installing it and then having searched search the Github issues.

That happens to me all the time. It helped cement my habit of binding the python version to the project with direnv and a flake.nix so I end up switching to the right version when I cd to the project dir.

Re: The tragedy of running an old Node project

#394

Post by phatskat »

cies wrote: post #388
leptons wrote: post #387

Earlier quoted context omitted.

Typescript is still nowhere near as popular as Javascript, and likely never will be. It's overkill for the vast number of uses of Javascript.

JS's uses have been growing steadily. The language was clearly not "designed" (I saw a talk about the first 10d of JS, little actual designing happened). TS is to the rescue when you have a big JS project, because that's what JS is not good at: big projects and large teams.

I’d love a link to this talk if you happen to have it handy!

Re: The tragedy of running an old Node project

#395

Post by paulddraper »

tmpz22 wrote: post #52
hathawsh wrote: post #45

Earlier quoted context omitted.

I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated vers…

> That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas. I disagree. This is an easy problem to avoid with minimal due diligence, people just choose convenience and make unnecessary trad…

> Use the standard library (ironically not available for Node projects)

???

Node.js has an extensive stdlib [1].

Contrast that with Python which practically requires a 3rd party HTTP client.

Or Java that doesn't even have JSON support.

[1] https://github.com/nodejs/node/tree/main/lib

Re: The tragedy of running an old Node project

#396

Post by paulddraper »

blenderob wrote: post #167
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.

Lol, Go was notorious for breaking with its "pull from main"/lack of lockfile approach.

Re: The tragedy of running an old Node project

#397

Post by banku_brougham »

Suppafly wrote: post #294
andai wrote: 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…

applet. thats a name i havent heard in a very long time.

Re: The tragedy of running an old Node project

#398

Post by leptons »

cies wrote: post #388
leptons wrote: post #387

Earlier quoted context omitted.

Typescript is still nowhere near as popular as Javascript, and likely never will be. It's overkill for the vast number of uses of Javascript.

JS's uses have been growing steadily. The language was clearly not "designed" (I saw a talk about the first 10d of JS, little actual designing happened). TS is to the rescue when you have a big JS project, because that's what JS is not good at: big projects and large teams.

Except big JS projects with large teams existed well before Typescript ever did, and it never stopped anyone from producing good results. Typescript really isn't making anything possible that wasn't possible before Typescript existed.

Re: The tragedy of running an old Node project

#400

Post by signal11 »

KronisLV wrote: post #217
ivan_gammel wrote: post #179

Earlier quoted context omitted.

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

Old Spring versions < 6.1 are obsolete, so you do have to upgrade Spring in many scenarios as well. No security fixes for them unless you pay for support.
Post reply on HN