javy VS js-compute-runtime

I don't think you can compile JS to WASM... You can run your JS code in a sandboxed runtime implemented in WebAssembly, which... I guess gives you sandboxing, but not much else.

Yes exactly! Thanks for nudging me in the direction of: - https://github.com/Shopify/javy - https://github.com/WebAssembly/design/issues/219

I’m not sure if anyone has done so yet for Go, but Shopify has done this for Rust.

https://github.com/Shopify/javy/tree/main/crates/quickjs-was...

> - JS is notably missing from the list of languages supported on the front page. But I see mentions of a Spidermonkey.wasm in the blog post. Is running JS on top of wasmtime in production a realistic prospect today? If so, where can I read more? (mainly interested in this for the instantiation time benefits, though maybe all/most of that will be negated by the embedded JS engine?)

Shopify and others use QuickJS as their JS engine of choice. See https://github.com/Shopify/javy as a starting point. The real benefit is allowing authors of plugins to write JS and not AssemblyScript, not any performance or instantiation time benefits.

> - How should I go about building a typical web service on top of wasmtime? Can wasmtime itself handle network requests/connections or would I need to build the web server in some other host language and pass request data to wasmtime modules? Haven't been able to find anything in the docs about this.

There are a lot of choices for this. None I would consider mature, but some leads:

- https://github.com/deislabs/wagi

You will need to use something like javy which incidentally accepts input via stdin and produces output via stdout which would work perfectly (to my knowledge) as a wasi worker.

yes it has, https://github.com/Shopify/javy among others

There are multiple JavaScript runtimes. SpiderMonkey is one example that has nothing to do with Node.js, see (js-compute-runtime)[https://github.com/fastly/js-compute-runtime].

We listened to the community feedback, filled in feature gaps, and addressed many bugs in the SDK. Not only that, we’ve also overhauled the SDK reference docs making it easier for you to know what’s supported and how to implement the features. All the Fastly specific features of the JS SDK now have interactive example applications in the documentation.

These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:

1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.

2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/

3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.

btw. for what it's worth their javascript to wasm is opensource:

- https://github.com/fastly/js-compute-runtime

- https://github.com/tschneidereit/spidermonkey-wasi-embedding

and besides that it is slower than nodejs it is still plenty fast (no matter that it is not as fast as they want) btw. it's startup is faster than node. (maybe better pgo might help)