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

291–300 of 412 posts

Re: The tragedy of running an old Node project

#291

Post by neonsunset »

thrw42A8N wrote: post #289
neonsunset wrote: post #205

Earlier quoted context omitted.

This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can down…

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 unmaintained JS project cannot be compared. The average dependency graph of a .NET project is going to be 10 times smaller too.

Re: The tragedy of running an old Node project

#292

Post by contingencies »

FWIW, I've mostly maintained long term PHP projects, and I've had nearly unaltered codebases running for ~25 years since php3. No frameworks, just core PHP. People dump on PHP, but it's a very good tool if you're focused on maintainable output and pick the right functional APIs to cede to mature unix tools. You can expect decades of solid, maintainable output.

Experienced programmers will not pick up a "built on shifting sand" stack, because they can acutely perceive the pain and suffering before it happens, generally from past experience. With fast-crumbling stacks, you need to execute quickly and move on, and treat the whole codebase as an expiring entity. Stacks I personally try to avoid: anything node/javascripty, anything Androidy, anything iDevicey.

Those who don't understand Unix are condemned to reinvent it, poorly. - Henry Spencer

... via https://github.com/globalcitizen/taoup

Re: The tragedy of running an old Node project

#293

Post by the_mitsuhiko »

cle wrote: post #273
the_mitsuhiko wrote: post #223

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. The same problem in Python is much easier now because you can ask the uv resolver to limit itself to some earlier point in time. You can do `uv pip install --editable . --exclude-newer=2022-01-01` and you will end up with a resolution from two years ago. Since uv can also install older python versions automatic…

Will uv even be around in 4+ years? No idea.

I don't know either, but think even if it's not, whatever will replace it, will at least have to achieve feature parity.

Re: The tragedy of running an old Node project

#294

Post by Suppafly »

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

>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 ones to run.

Re: The tragedy of running an old Node project

#295

Post by leptons »

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.

A standard library is not a "language" feature.

Re: The tragedy of running an old Node project

#296

Post by leptons »

cies wrote: post #170
skeletal88 wrote: post #125

Earlier quoted context omitted.

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`,…

It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me. And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV.

Re: The tragedy of running an old Node project

#297

Post by yoelhacks »

peutetre wrote: post #147
yen223 wrote: post #146

Earlier quoted context omitted.

JavaScript will be killed off by webassembly for about 5 years now

The difference lately is the number of tools that are now in place for WebAssembly development and the new extensions to WebAssembly (WasmGC, Memory64, etc.). Despite 28 years of effort at optimization, JavaScript is outperformed by WebAssembly. There's not much coming back from that: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi... https://www.amazon.science/blog/how-prime-video-updates-its-... https:…

Javascript is outperformed by WebAssembly in the sense that it runs faster.

A lot of things that bring a lot of value to a lot of people are still much, much faster to build via the JS / TS ecosystem.

It absolutely makes sense that calculation-heavy workloads will be ported to WASM, but there's a lot more to building an app.

Re: The tragedy of running an old Node project

#298

Post by nitwit005 »

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…

Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java.

The company I work at has a ton of projects stuck on ancient spring versions and Java 8 (or Java 6 in one instance). They still insist on Spring despite being essentially unable to upgrade to a version newer than a decade old.

Re: The tragedy of running an old Node project

#299

Post by microtonal »

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.

Just to try it out, I took one of my old C projects written in 2010, last code update in 2012. It's a machine learning utility to train maximum entropy rankers. I was a bit worried because it used CMake (rather than a vanilla Makefile). It configured and built without any issues (and super-fast).

Re: The tragedy of running an old Node project

#300

Post by microtonal »

Cu3PO42 wrote: post #246
dmuth wrote: post #220

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.

This works as long as your Dockerfile is reasonably reproducible and does its best to lock dependencies. However, this approach has failed me a couple of times in the past. For example, I rebuilt a container some weeks later, in the meantime a new version of clang had been released that just so happened to break my build due to a bug. I personally use Nix these days, but the complexity is too high for me to recommend…

Yeah, Nix pretty much solves this problem. The other day I wanted to try a really old version of spaCy for fun/historic interest. spaCy 1.8.2 installed freshly from the binary cache on NixOS-unstable as if it was still April 2017.
Post reply on HN