4 ms·
QuickJS is a simple interpreter, no JIT, so performance obviously won't be competitive with V8. The appeal is that it supports most of ES2019 while being a e
by the_duke 6y ago
QuickJS is a simple interpreter, no JIT, so performance obviously won't be competitive with V8.
The appeal is that it supports most of ES2019 while being a easy to build, light weight dependency that can be embedded into Rust applications. [1]
Would I use something like this for a production service with a high traffic volume? It would be nice to see benchmarks, but most likely not.
But if you have a Rust backend and want a simple way to do SSR without having to operate a separate Node service or linking v8, this might be a neat approach.
ps: It would be nice to run QuickJS in a WASM runtime, while still offering the same convenient API surface for Rust. This would provide sandboxing for the QuickJS C code. It's is in my backlog, I might get to it eventually. [2]
[1] https://github.com/theduke/quickjs-rs https://github.com/theduke/quickjs-rs
[2] https://github.com/theduke/quickjs-rs/issues/11 https://github.com/theduke/quickjs-rs/issues/11
- jgalvez 6y agoExactly where my thoughts are with this.
- JMTQp8lwXL 6y agoSlightly off topic, but is ES<CalendarYear> an actual thing, or common parlance for current capabilities? Officially, I thought there was only ES5, ES6, etc.
- Cu3PO42 6y agoYes, the standards have been named like that since 2015. In fact ES6 was renamed to ES2015. Since then there have been yearly "releases"/standard versions.
- amelius 6y agoPersonally I think it's a huge waste to re-write everything (badly) in Rust. Why not link against an existing JS compiler/interpreter written in another language?
- saghul 6y ago> ps: It would be nice to run QuickJS in a WASM runtime Not sure if it helps, but I did that some time ago, with minor QuickJS patching: https://github.com/saghul/wasi-lab/tree/master/qjs-wasi https://github.com/saghul/wasi-lab/tree/master/qjs-wasi