The benchmark scores [1] he gives only stack it up against other embeddable engines. It cuts those to ribbons, but can someone who's familiar with JavaScript performance weigh in on how it competes with the most popular engines like V8 and SpiderMonkey? It would be interesting if this is so fast that you could re-implement Node using QuickJS instead of V8, or even make a WebKit- or Gecko-based browser with QuickJS under the hood. Presumably a lot of the headaches with swapping in a new JS engine have to do with dependencies, and this has none.
I have a small, CPU-intensive benchmark which shows the performance of QuickJS to be comparable to other interpreters written in C. It's on par with MicroPython and recent versions of Ruby, and a little faster than CPython and Lua.
However, it's still 2-3x slower than the optimized, CPU-specific interpreters used in LuaJIT and V8 (with their JITs disabled), and 20-100x slower than the LuaJIT, V8 and PyPy JIT compilers.
If the scoring scheme works the same as the results he shows on the site (higher is better), then V8 is still far faster than QuickJS. Which wouldn't be all that surprising since the V8 folks have spent hundreds of thousands of man-hours on optimization and JIT magic, which is something that would be hard to duplicate, to say the least, in a ~1.5MB all-interpreted engine.
We usually forget the purpose of scripting languages.
Main purpose of them is to be a glue between native calls:
take output of one native function and pass it as input to other. So instead of writing ray-tracer in JS you should write it as a native function (not even in webasm).
Either to use a) some compileable language (of V8 with JIT) or to use b) something small but to provide easy ways to extend script by custom native functions.
I've chosen b) and so the engine that does HTML/CSS and scripting is 6 times more compact than just only V8 binaries. For an embeddable engine that is clearly better.
For browsers, where running JS and no real ways for native code execution... they MUST have V8 and the like.
That also leads to Electron problems... browser engines are simply not suitable to be used as embeddable UI engines, by design.
It shows only 2~3% of V8 performance. But it enough for running simple embedded script. And thing is it meets JS standards. At starting you can embed it into your SW easily, and provide scripting functionality. And when your SW grow enough, and have heavy scripts, you can migrate to V8 since there is compatibility.
[1] https://bellard.org/quickjs/bench.html