The tragedy of running an old Node project

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.

Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.

Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability.

There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point.

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

Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.

> Well, the article is about npm, a package manager for node.

And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.

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

Well, I would spend probably similar time to get started on Pascal, which I used last time in the previous century. I would not blame Pascal for it though.

Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes.

It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem.

If node saved you 8 seconds per working day over those 4 years, you’d still be ahead spending 2 more hours on that node project every 4 years.

Pinning to exact versions has been supported in npm for most, if not all of its life.

That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable).

Plus even if you were using lots of deps, the Go code would almost certainly keep working, thanks to minimal version selection and the Go module mirror. (And of course for maximum reliability, could even easily vendor deps with "go mod vendor".)

JavaFX? I’ve been there too, had to install it with maven and waste a few hours getting the maven xml just right for it to bundle the entire thing into a runnable jar (one that doesn’t require shipping extra files). Not the most convenient, but I get that they wanted to split it off the JDK release cycle.

Might be an unpopular opinion but I like it that way. It means that I can pull an old Gradle version and the build should succeed. Unlike maven where I’ve been bitten by plugin xml syntax changes and such.

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

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.

> 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?

`make` works pretty well on ... everything I've written that I kept since then.

`cmake ..` otoh, tends not to.

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.

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

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.

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

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

That's the reality of using the language in production projects.

Same as how you're likely to see more than just Python or Node being used in projects that list them in the tech stack, because there's native dependencies and tooling used.

They had mmap, but it was dropped at some point, I guess.

They do have syslog though https://pkg.go.dev/log/syslog

`make` itself works fine, that hasn't changed in decades. That doesn't mean the tooling `make` scripts kick into gear still exist, or work, or do the same things, though. Makefiles don't fix the dependency on a fifteen year old C compiler.

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

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.

I know this is a late response, but for anyone curious you would need to use an official Oracle or Sun JDK/JRE from Java 8 or older. OpenJDK doesn't include support for applets.

You also need a browser that has NPAPI. IE 11 was the most modern browser I am aware of that still supported applets.

The old GUI framework mentioned in the GP might have been Swing. It is still included in most JDKs and allows for cross platform desktop GUI application development with no other dependencies outside the JDK. Finding documentation on how to do GUIs in Swing is getting increasingly difficult though.

IIRC Oracle makes it really hard to find the download. Admittedly we didn't spend more than an hour or two messing around with all of it and getting the applets to run wasn't a high priority or anything.