3 ms·

On anything you can self-run it's a very useful qualifier. Personally I ignore anything that says "written in Node" because I don't want those headaches.

Aeolun 5y ago
That’s a shame. Node is quite easy to run. Biggest problem is that installing any app includes a free black hole.
- vaughan 5y ago
  JS and Rust are best friends. Deno is written in Rust. And many Node native libs are being written in Rust.
  - Popegaf 5y ago
    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.
    - vaughan 5y ago
      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.
- tluyben2 5y ago
  ... 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.
- vagrantJin 5y ago
  > includes a free black hole. This is gospel at this point. Npmming and yarning are giving me anxiety these days.
zbrozek 5y ago
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.
OJFord 5y ago
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!
- brabel 5y ago
  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.
  - nick__m 5y ago
    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.
  - vips7L 5y ago
    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.
    - brabel 5y ago
      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.

Aeolun 5y ago

That’s a shame. Node is quite easy to run. Biggest problem is that installing any app includes a free black hole.

vaughan 5y ago
JS and Rust are best friends. Deno is written in Rust. And many Node native libs are being written in Rust.
- Popegaf 5y ago
  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.
  - vaughan 5y ago
    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.
tluyben2 5y ago
... 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.
vagrantJin 5y ago
> includes a free black hole. This is gospel at this point. Npmming and yarning are giving me anxiety these days.

zbrozek 5y ago

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.

OJFord 5y ago

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!

brabel 5y ago
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.
- nick__m 5y ago
  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.
- vips7L 5y ago
  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.
  - brabel 5y ago
    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.