i wouldn’t say “performance” as an advantage of running JS in QuickJS. QuickJS isn’t competitive at all with the host JS VM, although I guess it’s faster than older C interpreters, or an interpreter implemented in JavaScript.
I suppose you get performance benefits if the the time it takes to start up a nodejs process dominates the execution time of the script. This is probably the case for a decent proportion of “serverless function” type scripts.
Not true, QuickJS works completely standalone. I've used it to compile NodeJS libraries into standalone libraries that other C libraries can call, even on a system without a NodeJS install.
This post is about a quickjs-in-node library that wraps the quickjs C library, not quickjs itself. My original comment is responding to a comment by the author of the library.
Yup, AWS actually created a JS runtime called LLRT (Low Latency Runtime) based on QuickJS exactly for this purpose (reducing Lambda function cold start time). The Syntax podcast just released an episode with one of the developers behind LLRT.
I don't want to take any credit away from Fabrice Bellard and his work on QuickJS. All of the serverless QuickJS derivatives like Shopify's Javy and AWS's LLRT owe a debt of gratitude to Bellard. They're all very thin wrappers over QuickJS (which is by design obviously in order to reduce cold start times). Use whichever verb you prefer in place of 'created'.
