js-compute-runtime VS sw-transfer-stream

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)

To achieve this specific task, once an HTML page is loaded into the browser, and a ServiceWorker is registered for that scope, the server does not need to remain active to maintain the functionality of intercepting requests from the Web page (popup window) to the ServiceWorker, where the ServiceWorker can itself make requests to, for example, the same local server to execute parec and pipe output to multiple EventSource responses within the same initial connection, or pipe data to a single ReadableStream served with Response() and event.respondWith(), e.g., see https://github.com/guest271314/offscreen-webrtc, https://github.com/guest271314/sw-transfer-stream.

I've already built it https://github.com/guest271314/captureSystemAudio#web-accessible-resources-transferable-streams-media-capture-transform-breakout-box, https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/capture_system_audio.js; see also https://github.com/guest271314/sw-transfer-stream and https://github.com/guest271314/offscreen-webrtc. I'm just trying to reduce steps https://github.com/guest271314/requestClient.

Yes, you can create an iframe and/or a new window that you have complete control of to execute arbitrary code using either localhost or an extension; e.g., https://github.com/guest271314/sw-transfer-stream, https://github.com/guest271314/offscreen-webrtc.

Open new window to transfer data from ServiceWorker to arbitrary Web page https://github.com/guest271314/sw-transfer-stream

There are workarounds which involve using an iframe https://github.com/guest271314/persistent-serviceworker/tree/main/chromium_extension_web_accessible_resources_iframe_message_event or window.open() https://github.com/guest271314/sw-transfer-stream or and offscreen document https://github.com/guest271314/offscreen-webrtc with WebRTC - however that involves loading an entire HTML document, and each has its own deficienfies - with all of the Window features that we do not really need just to transfer data between the Web page I have control of and the ServiceWorker I have control of.