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.