Web APIs support about javy

[jeffcharles]

I hear the the frustration of wanting to use Javy in a browser environment out of the box and to able to use it in a similar capacity to Emscripten. I understand how convenient it would be.

To provide some context on why this is not currently feasible in Javy, we want to make it easy to run Wasm modules produced by Javy in a wide variety of WebAssembly runtimes including in a number of non-JavaScript environments outside the browser (for example, Wasmtime, Wazero, among others). To do that, we try to ensure Javy modules only import functions that are defined as part of WASI preview1 because host implementations for these functions are available for a wide variety of WebAssembly runtimes. Requiring host runtimes to implement additional Javy-specific functions to run Javy modules means that modules produced by Javy could not run in the same wide variety of host environments. To give you a concrete example, it's not currently possible to run WebAssembly modules compiled by Emscripten on Wasmtime because modules generated by Emscripten import Emscripten-specific functions that are not defined in Wasmtime. Unfortunately supporting a number of Web APIs would require the use of imported functions that are not defined as part of WASI preview1. For example, there isn't currently an API available in WASI preview1 to create a network request. So trying to add support for fetch would mean Javy modules would require the host runtime to implement a non-standard function to be able to successfully instantiate. And that would mean that Javy modules would only be runnable on a much smaller set of Wasm runtimes than is the case today.

We are exploring options for improving Javy's extensibility as well as keeping an eye on ongoing work with the Wasm Component Model and WASI preview2 which may make supporting additional Web APIs more feasible in the future.

[gc-victor]

Somehow related to this topic, I have released a JS-Runtime based on quickjs-wasm-rs. While it does not encompass the entire Minimum Common Web Platform API proposal, it does include the implementation of the Fetch API.

https://github.com/gc-victor/js-wasm-workers-runtime
https://common-min-api.proposal.wintercg.org/

[bytezeroseven]

@jeffcharles I have a question. I am assuming this tool just embeds a js engine and makes it run our js code. So js code isn't really converted to anything else and remain as it is? I mean if it only embeds a js engine and makes it run our js code, js code can be extracted easily.
Or is the js code actually converted into bytecode?

Not related to this, but in the past week, I actually ended up making a system on top of assemblyscript for accessing every web API from the wasm side. Its not yet public though. Below is a screenshot of its syntax.

[jeffcharles]

I am assuming this tool just embeds a js engine and makes it run our js code. So js code isn't really converted to anything else and remain as it is?

We compile the JS source code to QuickJS bytecode as part of the javy compile ... invocation and the QuickJS bytecode is stored in one or more data segments in the Wasm module that's produced.

I mean if it only embeds a js engine and makes it run our js code, js code can be extracted easily.

Agreed. We have a dynamic linking mode that can be activated with the -d flag when using javy compile and that creates a Wasm module that just contains the QuickJS bytecode and a small number of instructions to invoke functions in a different Wasm module to drive the interpreter. The interpreter Wasm module can be obtained by running javy emit-provider ....

[jeffcharles]

I'm going to close this for now as we're not planning on adding Web API support to this project for the time being. I suggest using the quickjs-wasm-rs crate directly. It's what Javy uses to execute JS source code in a Rust application that's been compiled to Wasm. You can use the eval_global and wrap_callback functions on Context to add the APIs you would like into the context that the JS code is evaluated inside.