Fork me on GitHub
#nbb
<
2023-12-08
>
sher10:12:44

@borkdude curiosity question Now that squint and nbb have been given much effort and performing well, can you share a shortcomings list of Node.js as a host, comparing to JVM?

borkdude10:12:17

I think you could generalize the question to: what are the differences between JVM and Node.js? You could post this in the #C03RZGPG3 channel and I'm sure many people will have opinions on this. Most will be in favor of JVM Clojure since that's just what most people use in Clojure-land

sher10:12:23

thanks2 will ask in off-topic

sher10:12:19

I was wondering about your findings.

borkdude10:12:18

JVM is better suited for long running server processes since it has generally better performance, but with short running cloud functions, it doesn't matter that much for that specific use case and Node.js could be as viable for it, even more since it has better startup and memory usage than a full JVM (although GraalVM native-image and babashka solve that to some degree for JVM Clojure). For scripting, the light-weight-ness of Node.js and the big ecosystem is a nice environment, but async/await and the churn of JS library APIs can be discouraging for people who are used to Clojure's stability. I started nbb because sometimes in the bb ecosystem there aren't good libraries for some scripting tasks, and there's always a JS library. squint and cherry aim to give better performance + js-await and in this way, could try to be better than nbb.

sher11:12:49

Right, Clojure community can find it difficult to adopt the havoc of JavaScript ecosystem with all the backwards incompatibility etc. Thank you for a comprehensive answer.

Ed17:12:19

in addition - be wary of js numbers. They are all floats, and will start to loose precision as you get to large numbers, for example.

upvote 1
borkdude18:12:14

In squint async programming is a little easier due to js-await being supported

🎩 1