wasmedge-quickjs VS SSVM

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

WasmEdge GitHub address: https://github.com/WasmEdge/WasmEdge.

I see that they recently changed the intro of WasmEdge on Github [1] to " WasmEdge is the easiest and fastest way to run LLMs on your own devices. "

Since it's a wasm runtime capable of many things I find bizarre that they now start describing it with a ultra-specific use case

- [1] https://github.com/WasmEdge/WasmEdge

Mmm…

The wasm-nn that this relies on (https://github.com/WebAssembly/wasi-nn) is a proposal that relies of arbitrary plugin backends sending arbitrarily chunks to some vendor implementation. The api is literally like set input, compute, set output.

…and that is totally non portable.

The reason this works, is because it’s relying on the abstraction already implemented in llama.cpp that allows it to take a gguf model and map it to multiple hardware targets,which you can see has been lifted here: https://github.com/WasmEdge/WasmEdge/tree/master/plugins/was...

So..

> Developers can refer to this project to write their machine learning application in a high-level language using the bindings, compile it to WebAssembly, and run it with a WebAssembly runtime that supports the wasi-nn proposal, such as WasmEdge.

Is total rubbish; no, you can’t.

This isn’t portable.

It’s not sandboxed.

If you have a wasm binary you might be able to run it if the version of the runtime you’re using happens to implement the specific ggml backend you need, which it probably doesn’t… because there’s literally no requirement for it to do so.

There’s a lot of “so portable” talk in this article which really seems misplaced.

WasmEdge isn't there yet: https://github.com/WasmEdge/WasmEdge/issues/1122#issuecommen...

Example 1: Analyze the content and risks of each commit in the PR. Then make a summary. https://github.com/WasmEdge/WasmEdge/pull/2394#issuecomment-...

There has also been a few "cloud-native" runtimes based on WASM, like WasmEdge but there's a few others (can't remember their names!)...