3 ms·

What's the current state of QuickJS? Is there anywhere it's a clearly better choice? Does it have a shot of being a top class engine?

rfoo 2y ago
> Is there anywhere it's a clearly better choice? Embeddable use when you need latest ECMAScript support. > Does it have a shot of being a top class engine? No.
- akie 2y ago
  Why does it not have a shot of being a top class engine?
  - petters 2y ago
    Performance
  - masklinn 2y ago
    Because the main goals are to be small, embeddable, and have low startup time. A top class engine requires a JIT and that generally leads to being large and having high startup time. LuaJIT is pretty much the exception which proves the rule and 1. Mike Pall is a monster of a developer not unlike Bellard; and 2. Pall is on record (in discussions with other JIT people) that in his opinion you can’t bolt a JIT to an existing runtime and get a maximally efficient JIT. So you’d need someone of that class of skill to decide to make that their legacy.
    - lifthrasiir 2y ago
      And it's not like that Bellard is unable to produce a JIT compiler; see, for example, QEMU dyngen [1] which eventually inspired CPython's new JIT compiler. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu...
  - rfoo 2y ago
    Like other replies said, having JIT requires quite different tradeoffs to be made. And unfortunately, making a very fast interpreter-based JS engine is a tedious and human-power-heavy work, it involves a lot of work which can't be eliminated by better skills.
m1el 2y ago
From my observations: cold start, ease of patching. If you're running a lot of different JS code or restarting the code frequently, it's faster than node. Where it's useful: fuzzing. If you have a library/codebase you want to fuzz, you need to restart the code from a snapshot, and other engines seem to do it slower. It's also really easy to patch the code, because of the codebase size. If you need to trace/observe some behavior, just do it.
benatkin 2y ago
Apparently Figma still uses it for plugins, so there's that. It can be compiled to WebAssembly and run with the sandboxing of WebAssembly. Not just data sandboxing but sandboxing that can prevent it from slowing down the rest of the app (though it runs slower). Post from Figma in 2019: https://www.figma.com/es-la/blog/an-update-on-plugin-security/?context=confirmLocalePref https://www.figma.com/es-la/blog/an-update-on-plugin-securit... This in 2023: "Either Figma hasn't updated QuickJS since, or they've moved to a different VM, because Figma's VM is missing many of the features QuickJS now supports." https://www.sam.today/blog/bumbling-the-figma-api https://www.sam.today/blog/bumbling-the-figma-api

rfoo 2y ago

> Is there anywhere it's a clearly better choice? Embeddable use when you need latest ECMAScript support. > Does it have a shot of being a top class engine? No.

akie 2y ago
Why does it not have a shot of being a top class engine?
- petters 2y ago
  Performance
- masklinn 2y ago
  Because the main goals are to be small, embeddable, and have low startup time. A top class engine requires a JIT and that generally leads to being large and having high startup time. LuaJIT is pretty much the exception which proves the rule and 1. Mike Pall is a monster of a developer not unlike Bellard; and 2. Pall is on record (in discussions with other JIT people) that in his opinion you can’t bolt a JIT to an existing runtime and get a maximally efficient JIT. So you’d need someone of that class of skill to decide to make that their legacy.
  - lifthrasiir 2y ago
    And it's not like that Bellard is unable to produce a JIT compiler; see, for example, QEMU dyngen [1] which eventually inspired CPython's new JIT compiler. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu...
- rfoo 2y ago
  Like other replies said, having JIT requires quite different tradeoffs to be made. And unfortunately, making a very fast interpreter-based JS engine is a tedious and human-power-heavy work, it involves a lot of work which can't be eliminated by better skills.

m1el 2y ago

From my observations: cold start, ease of patching. If you're running a lot of different JS code or restarting the code frequently, it's faster than node. Where it's useful: fuzzing. If you have a library/codebase you want to fuzz, you need to restart the code from a snapshot, and other engines seem to do it slower. It's also really easy to patch the code, because of the codebase size. If you need to trace/observe some behavior, just do it.

benatkin 2y ago

Apparently Figma still uses it for plugins, so there's that. It can be compiled to WebAssembly and run with the sandboxing of WebAssembly. Not just data sandboxing but sandboxing that can prevent it from slowing down the rest of the app (though it runs slower). Post from Figma in 2019: https://www.figma.com/es-la/blog/an-update-on-plugin-security/?context=confirmLocalePref https://www.figma.com/es-la/blog/an-update-on-plugin-securit... This in 2023: "Either Figma hasn't updated QuickJS since, or they've moved to a different VM, because Figma's VM is missing many of the features QuickJS now supports." https://www.sam.today/blog/bumbling-the-figma-api https://www.sam.today/blog/bumbling-the-figma-api