Emscripten / WASI support

[saghul]

I'm not sure what the status of the Emscripten support is... Perhaps we could run a CI for it, if we care to keep it.

In a similar line, I added WASI support 4 years ago (time does fly!) here: https://github.com/saghul/wasi-lab/tree/master/qjs-wasi Do we want to adopt support for WASI?

Either of them is useful to implement a sandbox in a browser, so it would be nice to have at least some support for it IMHO.

[bnoordhuis]

I don't care about emscripten myself but I suppose one of quickjs's selling points is that you can run it in a browser or a WASM sandbox. I can be persuaded either way: keep and test, or simply remove.

Talking about WASM... WASM or WASI? WASI is more of an embedder concern. What would you change in quickjs in order to accommodate it?

WASM support would make sense but increases the number of bytecode interpreters from 2 to 3 (libregexp is the other one) :-)

The WASM GC extension requires pretty tight integration with the JS runtime so we'd probably have to write an engine from scratch rather than integrating an existing project (and also, where's the fun in that?)

I wrote a WASM JIT a few years ago and it's fairly straightforward, just a lot of work.

[saghul]

Talking about WASM... WASM or WASI? WASI is more of an embedder concern. What would you change in quickjs in order to accommodate it?

I just had to do some ifdefs to get it to compile with wasienv. The resulting WASM file works in the browser too IIRC.

WASM support would make sense but increases the number of bytecode interpreters from 2 to 3 (libregexp is the other one) :-)

LoL you mean adding WASM support to QuickJS? I'd love that since wasm3 seems to no longer be maintained, but that yak is hairier than my razor is sharp right now :-P

The WASM GC extension requires pretty tight integration with the JS runtime so we'd probably have to write an engine from scratch rather than integrating an existing project (and also, where's the fun in that?)

I wrote a WASM JIT a few years ago and it's fairly straightforward, just a lot of work.

It would indeed be cool to have in the future for sure.

[saghul]

I made justjake/quickjs-emscripten#124 let's see how that goes :-P

[paulocoghi]

IMHO one crucial improvement that QuickJS needs is more performance, instead of things like WASM / WASI support.

If it became fast and continues to be lightweight, it would be a huge advantage.

[saghul]

PRs are welcome :-)

[simonw]

The thing that interests me most about QuickJS is its potential for WebAssembly.

I have two problems I want to solve with it:

• I'd like to be able to take untrusted JavaScript code and execute it in a user's browser within my own web application, without risk that the JavaScript code could steal cookies, trigger actions on behalf of the user etc. Being able to run that code in QuickJS inside a WebAssembly sandbox in the user's browser would be ideal.
• I want to be able to execute untrusted JavaScript code server-side as well - again, using server-side WebAssembly and QuickJS.

An example of a feature I'd like to build here is a tool that lets users select a table full of their own data, then say "execute this snippet of JavaScript against every row and populate a column with the result". https://simonwillison.net/2023/Dec/1/datasette-enrichments/ explains this kind of feature in more detail.

[saghul]

Hi @simonw ! Huge fan of your work and your LLM related posts and presentations!

I think what you need could be accomplished with https://github.com/justjake/quickjs-emscripten which is a QuickJS build and sandbox using Emacripten.

I have a PR open updating the QuickJS version to the latest NG, I hope it can land soon!

[simonw]

Thanks, yeah that does look like what I'm looking for here:

• Update to QuickJS-ng justjake/quickjs-emscripten#124

[justjake]

I started releasing quickjs-ng Emscripten build variants for quickjs-emscripten on NPM. The variant catalog is here: https://github.com/justjake/quickjs-emscripten/blob/main/doc/quickjs-emscripten-core/README.md, here's the NPM package for the release-sync build variant: https://www.npmjs.com/package/@jitl/quickjs-ng-wasmfile-release-sync

I should probably add some documentation of which quickjs-ng commit I'm publishing, for now you'd need to correlate NPM release tags with the vendored quickjs-ng copy here: https://github.com/justjake/quickjs-emscripten/commits/main/vendor/quickjs-ng

[saghul]

That's awesome, thank you!

[saghul]

I added WASI support in #264