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

311–320 of 412 posts

Re: The tragedy of running an old Node project

#311

Post by blizdiddy »

guappa wrote: post #301
mperham wrote: post #228

Earlier quoted context omitted.

> I think the experience of code rot is universal and increases with the amount of dependencies you have. This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory ) and excellent backwards compatibility.

> Go is especially good because of the large stdlib Come on… compare it with what java and python have.

Java can't even read/write json without third party libraries.

Tell me a single thing that Oracle has added to the standard library. As far as I can tell, more and more of what was once standard is now getting offloaded and trademark-washed with the eclipse and apache foundations.

Re: The tragedy of running an old Node project

#312

Post by YuukiRey »

This is the reason I ripped out Gatsby from every project where I could. Every six months I’d spend an entire evening fixing obscure problems that shouldn’t even exist just to get things running. And that’s not even considering actual breaking changes of which there were plenty.

Re: The tragedy of running an old Node project

#313

Post by sorokod »

andai wrote: post #226
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 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.)

To save you time in the future:

https://adoptium.net/en-GB/

Haven't used javaFX for a while but this is worth a shot

https://openjfx.io

Re: The tragedy of running an old Node project

#315

Post by cypressious »

demosthanos wrote: post #189
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.

Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later.

If you use the the Gradle wrapper, it will use the correct version and download it if necessary. If I'm not mistaken, that's the recommended approach.

Re: The tragedy of running an old Node project

#316

Post by guappa »

dartos wrote: post #302
guappa wrote: post #301

Earlier quoted context omitted.

> Go is especially good because of the large stdlib Come on… compare it with what java and python have.

What does Java or Python have in their stdlib that go doesn’t?

Well python has syslog, mmap, just to name a couple of things.

Re: The tragedy of running an old Node project

#317

Post by regularfry »

liontwist wrote: post #288
regularfry wrote: post #259

Earlier quoted context omitted.

Which bit is it that you object to? Edit to add: this wasn't intended as a gotcha question, so apologies if it came across as one. I have issues with a lot of details about how npm works and the ecosystem it supports. I think it's possible to avoid them, and aim for something more like a bundler or a cargo, but again there are issues there (certainly in the former's case, I have less experience of the latter). Gettin…

Sure, I didn’t take that negatively. Let me start with facts: - npm actually downloads multiple copies of each library, when needed to satisfy conflicting version requirements. - this is only possible due toruntime features of JavaScript. In most languages like C this causes symbol collisions. - I think this is a problem in Common Lisp too due to packages being global. Maybe there is a fancy way to rebuild packages a…

Yes, that "feature" of npm isn't something you'll find elsewhere. It's not inherent to the problem of version resolution. Just about anywhere else you'll just get an error message that the version resolution isn't possible, if there's no available combination to satisfy all the requirements.

That one design attribute of npm probably more any other feels like they did it because they could, not because it was a particularly good idea.

Re: The tragedy of running an old Node project

#318

Post by thrw42A8N »

neonsunset wrote: post #291
thrw42A8N wrote: post #289

Earlier quoted context omitted.

If you used pure Node.js, you wouldn't have any problems whatsoever, too.

Unlike Node projects, your dependencies don't break - they stay on nuget.org, and the projects compile just like they did when they were first implemented. Upgrading dependencies and project target is subject to the same restrictions as in other good languages. I know for sure that I can clone a random project on Github, hit `dotnet build` and usually expect it to work on the first try. The rate of bitrot for average…

Yeah, that's nice, unfortunately it's the built-in Microsoft stuff like WPF that keeps breaking between versions.

Re: The tragedy of running an old Node project

#319

Post by spacebanana7 »

peutetre wrote: post #304
spacebanana7 wrote: post #261

Earlier quoted context omitted.

Network effects are very strong for languages. Better query languages than SQL could exist, but there's so much existing code and expertise out there that it's not worth the effort. Better backend languages than Java can & do exist but don't have the same enterprise popularity. Developers, projects and companies have an immense incentives to target the most popular programming language.

JavaScript's one advantage was that it was the privileged language in the browser. It has lost that now. JavaScript has entered its Walking Dead phase. It will gradually be displaced by all languages compiling to WebAssembly.

JavaScript’s main advantage is being commonly familiar to most software engineers.

The English language similarly lost its position as the preeminent imperial language a long time ago, so too with Latin & Rome. It takes a long time for a popular language to die because everyone wants to speak what everybody else speaks.

Re: The tragedy of running an old Node project

#320

Post by ziml77 »

gre wrote: post #241
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.

I just today tried reviving an old v12.4 node project and node-gyp is trying to use python2 which I don't even have on my Macbook anymore.

That Python 2 crap hit me as well when working on an older project. It used node-sass which depended on node-gyp. Dealing with upgrading that was a pain because I had to upgrade so much more to get versions of everything that played nice together.

What really pissed me off about it was that Python 2 was already known to be nearing EOL when our project was started, so node-gyp should have been upgraded to work with Python 3 by then. And even more annoying was that node-gyp already had Node to run on, so why in the world was it coded to depend on Python at all!?

Post reply on HN