It's interesting, I suspect we all have our thing we avoid like that - for me it's Java stuff. I don't say that to 'defend' node, I'm no JS fan boy or particularly experienced with it, it just doesn't bother me the way Java stuff does - the dread I have for a Java stack trace appearing from something I'm trying to run is enough to make me see if there's an equivalent that ticks the same boxes in another language!

These days Java applications are supposed to embed the JVM using jlink images or even native installer (see jpackage). So you shouldn't even know if the app is written in Java when you run it.

As someone who now does more operation than devloppement, I want my server side Java app to run on a full JVM, attaching jconsle or jstack to a running process is so usefull. No other runtime on Linux gives the observability you get by default when you run on a full JVM.

On Windows that another story since you have ETW which is incredible and works with anything. But on Linux, if your application doesn't offer observability, you have to resort to strace and adhoc EBPF that you have to write, to diagnose a missbehaving application in production.

The problem with jpackage/jlink is that most teams are stuck on an antiquated runtime and those tools didn’t ship until Java 14 (correct me if I’m wrong about the version). My own company is still making new projects on Java 8.

At work, we use some pretty complex stuff in our builds, including linking to C libs, Groovy testing, Kotlin modules, as well as the majority of the code in Java. It took quite a lot of effort, but we managed to move to Java 11 this year.

It's great to be able to use new Java language/platform features. We're moving to Java 17 next year once the dust settles (it will be the first LTS release in 3 years and comes up this month - Sep 2021)... it will be a much easier migration as there's nothing like the big Java 9 barrier to cross.

I can't understand why anyone would start something new in Java 8, all traditional Java tooling already works really well with Java 11 and even Java 17.

> I can't understand why anyone would start something new in Java 8,

Quite frankly: they just don't know better and they just don't care. I could go on for pages, but in short the people running the show are just really inexperienced and are pretending not to be. I'm going to start applying for jobs soon as its beginning to feel hopeless.

That’s a shame. Node is quite easy to run.

Biggest problem is that installing any app includes a free black hole.

... if the application was written recently. Get something from last year on your 'now' computer and let the suffering begin. Without a docker setup, I really find node horrible vs let's say .NET Core, Java/Closure or Go. But ymmv. A project I inherited has node_modules of 780MB with 150k files with many deprecated and vulnerable ones in them pinned versions: I would not call that easy. I never had that with .net: usually you need a few nugets and if you update them, they still work. That I would call easy. I have used both (and java for over 20 years) for 10+ years, I just do not like the ecosystem (or language but that is ok with typescript and purescript and cljs): I have to anyway.

> includes a free black hole.

This is gospel at this point.

Npmming and yarning are giving me anxiety these days.

JS and Rust are best friends. Deno is written in Rust. And many Node native libs are being written in Rust.

It's not JS or node that's the problem, it's the JS ecosystem. Badly or too broadly defined dependencies can (and do) lead to pulling a new version of a dep that introduced a breaking API change and tada, you have to start hunting for the right version.

Most projects don't define the node version that their project runs on either, so what ran in node 8 might not run in node 14 now.

What's wonderful to run into is non-JS dependencies: node-gyp happens to be used here and there. Sometimes the native lib will be pulled, sometimes it will be built, who knows why. And node-gyp might then depend on python2 which might not even be present on newer distros anymore.

And so on and so forth. If it doesn't come in an AppImage or docker image, there's no chance I'm getting myself into a node mess.

Yep, I know the pain all too well. ESM is also currently a disaster as many popular packages migrate without transpiling to CJS and you cannot call ESM from CJS contexts.

As you said, it's good to separate the ecosystem from the language/runtime. Things will improve over time, but everything has just been in transition for so long. I dream of the day that transpilers are no longer needed and TypeScript is baked in to all browsers. Until then it is a mess.

> node-gyp might then depend on python2

`cmake-js` is the preferred option now. And Rust native deps don't have this issue.

Ditto. It's a good indicator of being a sloppily-written pile of dependencies I don't want to touch. I also discriminate against Electron software, at least as much as I'm able.