5 ms·

I see a few mentions of QuickJS, but they all refer to the fork of Bellard's QuickJS https://bellard.org/quickjs/ https://bellard.org/quickjs/, which I think de

I see a few mentions of QuickJS, but they all refer to the fork of Bellard's QuickJS https://bellard.org/quickjs/ https://bellard.org/quickjs/, which I think deserves a mention. It seems to be still active (last release 2025-04-26, GitHub mirror at https://github.com/bellard/quickjs https://github.com/bellard/quickjs shows some activity).

LinguaBrowse 1y ago
I had it in my head that quickjs-ng (https://github.com/quickjs-ng/quickjs https://github.com/quickjs-ng/quickjs) is now blessed as the official fork, with Bellard even making some contributions to it, but maybe I've got it wrong. Here's the latest (https://github.com/quickjs-ng/quickjs/discussions/258#discussioncomment-11276265 https://github.com/quickjs-ng/quickjs/discussions/258#discus...) clarifying the two forks, anyway.
- Sytten 1y ago
  Both are active now and they are diverging. It is kinda sad but Bellard seems to want to do his own thing. PRs are traded sometimes but as time goes on they will become different projects, I did suggest a name change (https://github.com/quickjs-ng/quickjs/discussions/1119 https://github.com/quickjs-ng/quickjs/discussions/1119)
- weiliddat 1y ago
  Cool thanks for the historical context
williamcotton 1y ago
Speaking of QuickJS, how does it compare to embedded Lua? In performance, memory overhead, C API, startup time?
- LinguaBrowse 1y ago
  No idea! The only benchmarks I'm aware of for QuickJS are against other JavaScript engines (https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html). That said, one thing I've heard a lot from NativeScript TSC members building on top of QuickJS is that QuickJS has staggeringly low overhead for calling C functions. In fact, I was shown benchmarks in which it calls native functions faster than JS functions (perhaps it's easier to optimise because JS functions have complications like closure capture to worry about). I imagine this has conceptual overlap with how V8's Fast API works.
- danbolt 1y ago
  I embedded it at a game studio for PC and game consoles a few years ago. We opted for JavaScript over Lua for reasons I can’t disclose, but runtime performance was sufficient for our needs. I liked having reference counting since the determinism gave our tech lead a bit of confidence before cert. We had some performance issues with marshalling and unmarshalling, but that was mostly due to API design and how our codebase was structured. As per usual, optimizing scripts was the best bang for buck.
- Sytten 1y ago
  I didnt do a formal test, but we use quickjs-ng/rquickjs as the basis for our scripting engine. Even with 20+ rust modules loaded it takes less than 4ms to spawn and we spawn a lot of them (multiple per http request that runs through the proxy).

LinguaBrowse 1y ago

I had it in my head that quickjs-ng (https://github.com/quickjs-ng/quickjs https://github.com/quickjs-ng/quickjs) is now blessed as the official fork, with Bellard even making some contributions to it, but maybe I've got it wrong. Here's the latest (https://github.com/quickjs-ng/quickjs/discussions/258#discussioncomment-11276265 https://github.com/quickjs-ng/quickjs/discussions/258#discus...) clarifying the two forks, anyway.

Sytten 1y ago
Both are active now and they are diverging. It is kinda sad but Bellard seems to want to do his own thing. PRs are traded sometimes but as time goes on they will become different projects, I did suggest a name change (https://github.com/quickjs-ng/quickjs/discussions/1119 https://github.com/quickjs-ng/quickjs/discussions/1119)
weiliddat 1y ago
Cool thanks for the historical context

williamcotton 1y ago

Speaking of QuickJS, how does it compare to embedded Lua? In performance, memory overhead, C API, startup time?

LinguaBrowse 1y ago
No idea! The only benchmarks I'm aware of for QuickJS are against other JavaScript engines (https://bellard.org/quickjs/bench.html https://bellard.org/quickjs/bench.html). That said, one thing I've heard a lot from NativeScript TSC members building on top of QuickJS is that QuickJS has staggeringly low overhead for calling C functions. In fact, I was shown benchmarks in which it calls native functions faster than JS functions (perhaps it's easier to optimise because JS functions have complications like closure capture to worry about). I imagine this has conceptual overlap with how V8's Fast API works.
danbolt 1y ago
I embedded it at a game studio for PC and game consoles a few years ago. We opted for JavaScript over Lua for reasons I can’t disclose, but runtime performance was sufficient for our needs. I liked having reference counting since the determinism gave our tech lead a bit of confidence before cert. We had some performance issues with marshalling and unmarshalling, but that was mostly due to API design and how our codebase was structured. As per usual, optimizing scripts was the best bang for buck.
Sytten 1y ago
I didnt do a formal test, but we use quickjs-ng/rquickjs as the basis for our scripting engine. Even with 20+ rust modules loaded it takes less than 4ms to spawn and we spawn a lot of them (multiple per http request that runs through the proxy).