wasmedge-quickjs VS extism

I'm impressed you're already leveraging the component model. I thought it wasn't quite ready for primetime yet, but it seems you're proving that wrong... I'll have to dig in more here, as I'm working embedding WebAssembly in a high performance storage engine.

Thanks for the notes! I hear you on QuickJS - I've seen approaches of folks trying to build more node compatibility on top of quickjs (ala https://github.com/second-state/wasmedge-quickjs), but have recently heard about spidermonkey in wasmtime. Do you have intuition for nodejs vs browser in terms of what people want in terms of compatibility?

"A high-performance, secure, extensible, and OCI-complaint JavaScript runtime for WasmEdge. Run JavaScript in WebAssembly" wasm-edge-quickjs

See potential problems #1 for its proposed changes https://github.com/second-state/wasmedge-quickjs/pull/82#iss...

https://github.com/second-state/wasmedge-quickjs/pull/82#iss...

Try the bot on a PR you're interested in:

I can conceptualize a way to convert JavaScript source code to WASM then convert WASM to C source code. I have considered just using WASM, however, that introduces yet another runtime to manage https://github.com/second-state/wasmedge-quickjs.

Technically you can create a C shared object and import that shared object into QuickJS, see https://github.com/rsenn/qjs-modules, also https://github.com/second-state/wasmedge-quickjs.

That was achieved with QuickJS here https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg, and here https://github.com/second-state/wasmedge-quickjs.

WasmEdge provides excellent support for JavaScript, including ES6 and NPM modules, async networking, the fetch API, React SSR, and even mixing Rust code with JS code. https://github.com/second-state/wasmedge-quickjs

Extism can be really useful for packaging up and running cross-language libraries!

The most clear information about it is at: https://extism.org, but its a bit focused on the primary use case for Extism, being a universal plugin system.

There is a C PDK (https://github.com/extism/c-pdk) which you'd probably want to use in a new wrapper around your library in C++, and compile it to wasm32 freestanding or WASI, but without emscripten. Extism doesn't currently have an interop layer to emscripten.

It may just be my own unique obsession to peek at the internals of .wasm, but if anyone else is curious:

https://modsurfer.dylibso.com/module?hash=ab6f4b2de9db171347...

u/nbittich - curious if you've tried to use your language as as a scripting language inside other apps? I took a peak at your browser wasm environment, and think we could hook up the `compute` entrypoint you have here[0], but I'm not certain what the `ctx` does without going super deep, and if it could be passed into an Extism function[1] (which is how I'd try to run it from within 16+ other languages).

[0]: https://github.com/nbittich/adana/blob/master/adana-script-w...

[1]: https://github.com/extism/extism

Yep, this is one of the initial motivations for creating Extism: https://github.com/extism/extism -- and it works across 16 host languages & 8 guest languages.

On the devx, there's definitely some rough edges around building and using Wasm. My company has been working on a framework to ease integrating Wasm into existing applications. One area it focuses on is providing easy data passing between the host program and the Wasm and vice versa. https://github.com/extism/extism We do not have WASI preview 2 support yet, but are interested in integrating it.