3 ms·

QuickJS is really cool! You can use it to embed JS code in a native binary, which is nice if you're trying to use a NodeJS library outside of the JS ecosystem.

QuickJS is really cool! You can use it to embed JS code in a native binary, which is nice if you're trying to use a NodeJS library outside of the JS ecosystem. I put together a proof of concept for this about a year ago, in case this is a use case you currently have: https://github.com/ijustlovemath/jescx https://github.com/ijustlovemath/jescx

ikari_pl 3y ago
stupid question but... doesn't Deno also promise that possibility? Or at least to compile a js app into a binary
- wild_egg 3y ago
  Even if it does, it's always nice to have other options with different trade-offs
  - schemescape 3y ago
    As an example, I had a Makefile that ran a JS engine a few hundred times and Deno had ~240ms of startup overheard (on a very slow computer) versus QuickJS having around 20ms. But when running CPU-intensive JS (Marked.js and highlight.js), Deno was roughly 6x faster. I wanted to try Bun, but it had some blocking bugs at the time (which have since been resolved—or so I’ve read).
- toastercat 3y ago
  Yes, although the sizes of the binaries differ greatly. See this [1] Twitter reply. A "hello world" example produced an ~85mb binary in Node and Deno, whereas QuickJS produced a 6MB binary. [1] https://nitter.net/kebsworld/status/1648488613351657474#m https://nitter.net/kebsworld/status/1648488613351657474#m
  - SahAssar 3y ago
    The standard library or use-cases are not even comparable though, right? If I wanted to make a HTTPS request in quickjs I'd probably need to pull in openssl, write a http parser, etc, etc. I might be wrong, but comparing quickjs to node/deno seems like comparing a aquarium pump to an electric car. They both contain engines that are driven by electricity, but the similarities stop there. They are both good at what they do, but I would never replace one with the other.
    - toastercat 3y ago
      No, you are right. Deno and Node include the V8 engine which was built by a team at Google for the Chromium browser. QuickJS was built by Fabrice Bellard for the purposes of making an embeddable JavaScript engine. They have completely different scopes. But it is not impossible that your use-case may not need HTTP or other functionality afforded by larger runtimes, in which case, I'd rather have a 6MB binary over an 85MB binary that has a bunch of things I don't need. > I might be wrong, but comparing quickjs to node/deno seems like comparing a aquarium pump to an electric car. My intention was not to compare QuickJS to Node/Deno, only their ability to create small binaries.
- ijustlovemath 3y ago
  From what I can tell, Deno doesn't allow you to compile JS code into a native library, which was my primary use case. Also, QuickJS is much easier for me personally to grok, and to integrate into my existing build system, so it was a no-brainer. The only time I'd prefer another runtime is if I had really high performance expectations, but if that was the case, I'd probably write a new implementation of the JS library in a performance focused language versus try to shoehorn JS into doing something it wasn't designed to do

ikari_pl 3y ago

stupid question but... doesn't Deno also promise that possibility? Or at least to compile a js app into a binary

wild_egg 3y ago
Even if it does, it's always nice to have other options with different trade-offs
- schemescape 3y ago
  As an example, I had a Makefile that ran a JS engine a few hundred times and Deno had ~240ms of startup overheard (on a very slow computer) versus QuickJS having around 20ms. But when running CPU-intensive JS (Marked.js and highlight.js), Deno was roughly 6x faster. I wanted to try Bun, but it had some blocking bugs at the time (which have since been resolved—or so I’ve read).
toastercat 3y ago
Yes, although the sizes of the binaries differ greatly. See this [1] Twitter reply. A "hello world" example produced an ~85mb binary in Node and Deno, whereas QuickJS produced a 6MB binary. [1] https://nitter.net/kebsworld/status/1648488613351657474#m https://nitter.net/kebsworld/status/1648488613351657474#m
- SahAssar 3y ago
  The standard library or use-cases are not even comparable though, right? If I wanted to make a HTTPS request in quickjs I'd probably need to pull in openssl, write a http parser, etc, etc. I might be wrong, but comparing quickjs to node/deno seems like comparing a aquarium pump to an electric car. They both contain engines that are driven by electricity, but the similarities stop there. They are both good at what they do, but I would never replace one with the other.
  - toastercat 3y ago
    No, you are right. Deno and Node include the V8 engine which was built by a team at Google for the Chromium browser. QuickJS was built by Fabrice Bellard for the purposes of making an embeddable JavaScript engine. They have completely different scopes. But it is not impossible that your use-case may not need HTTP or other functionality afforded by larger runtimes, in which case, I'd rather have a 6MB binary over an 85MB binary that has a bunch of things I don't need. > I might be wrong, but comparing quickjs to node/deno seems like comparing a aquarium pump to an electric car. My intention was not to compare QuickJS to Node/Deno, only their ability to create small binaries.
ijustlovemath 3y ago
From what I can tell, Deno doesn't allow you to compile JS code into a native library, which was my primary use case. Also, QuickJS is much easier for me personally to grok, and to integrate into my existing build system, so it was a no-brainer. The only time I'd prefer another runtime is if I had really high performance expectations, but if that was the case, I'd probably write a new implementation of the JS library in a performance focused language versus try to shoehorn JS into doing something it wasn't designed to do