jco

It works in the browser already: https://github.com/bytecodealliance/jco

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly. With regards to the JS ecosystem specifically there are 3 projects to know: https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodealliance/ComponentizeJS https://github.com/bytecodealliance/jco The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come. One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are gett

There's also JCO for creating JS based WebAssembly components. It's based on StarlingMonkey which I believe is slightly faster than QuickJS under web assembly. https://github.com/bytecodealliance/jco Benchmark numbers for request isolated JS hello world / React page rendering: JCO/wasmtime: 314µs / 13ms Bun process forking: 1.7ms / 8.2ms v8 isolate from snapshot: 0.7ms / 22ms TinyKVM: 52µs / 708µs Native with reuse 14µs / 640µs Numbers taken from our upcoming TinyKVM paper. Benchmark setup code for JCO/wasmtime is here: https://github.com/libriscv/kvmserver/tree/main/examples/was... (I suspect even if we are able to get TinyKVM into a state you'd feel comfortable with in the future it would still be an awkward fit for Datasette since nested virtualisation is not exposed on AWS EC2.)

No, the component model proposal is not part of the Wasm 3.0 release. Proposals only make it into a Wasm point release once they reach stage 5, and the component model is still under development and so is not trying to move through the phases yet. Unlike any of the proposals which became part of Wasm 3.0, the component model does not make any changes to the core Wasm module encoding or its semantics. Instead, it’s designed as a new encoding container which contain core Wasm modules, and adds extra information alongside each module describing its interface types and how to instantiate and link those modules. By keeping all of these additions outside of core Wasm, we can build implementations out of any plain old Wasm engine, plus extra code that instantiates and links those modules, and converts between the core wasm ABI to higher level in

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects Just a note, but there is burgeoning support for this in "modern" WebAssembly: https://github.com/bytecodealliance/jco/tree/main/examples/c... If raw WebIDL binding generation support isn't interesting enough: https://github.com/bytecodealliance/jco/blob/main/packages/j... https://github.com/bytecodealliance/jco/blob/main/packages/j... https://github.com/bytecodealliance/jco/blob/main/packages/j... Support is far from perfect, but we're moving towards a much more extensible and generic way to support interacting with the DOM from WebAssembly -- and we're doing it via the Component Model and WebAssembly Interface Types (WIT) (the "modern" in "modern" WebAssembly). What's stopping us the most from being very effective in browsers is the still-expe

> Jco: a native Javascript WebAssembly toolchain and runtime built for WebAssembly Components and WASI 0.2 > WebAssembly Components are an extension to WebAssembly to create strongly typed interfaces between different programs. WASI 0.2 is a re-work of the “WebAssembly System Interfaces” based on WebAssembly Components https://github.com/bytecodealliance/jco

WASI Co-chair here: WASI is for the Web as well as beyond. The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.

> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon. > These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient. The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers a

I use @wasmer/wasi for my npm package `trealla` (wasm port of a Prolog interpreter). For the most part I'm pretty happy with it, but the file size is quite large[1] (taking up around half my bundle size), and it looks like @wasmer/sdk is even larger (wasmer.sh downloads a 1.7MB gzipped wasm binary that I assume is the runtime). It's a tough sell to the frontend folks when my package is this big... currently I have my eye on jco[2] which I hope will be much lighter. No shade intended towards the Wasmer folks, I appreciate the work they've done. [1]: https://bundlephobia.com/package/@wasmer/wasi@1.2.2 [2]: https://github.com/bytecodealliance/jco

The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt. Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority. If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to fol

The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco (https://github.com/bytecodealliance/jco) soon. WASI Preview 2 will be done in December or January, giving component model users a stable set of interfaces to use for scheduling, streams, and higher level functionality like stdio, filesystem, sockets, and http on an opt-in basis. You should look at wit-bindgen (https://github.com/bytecodealliance/wit-bindgen) to see some of the languages currently supported, and more that will be mature enough to use very soon (https://github.com/bytecodealliance/componentize-py) Right now jco will automatically generate the JS glue code which implements a Component Model runtime on top of the JS engine's existing WebAssembly implementation. So, yes, Components are a composition of Wasm Modul

Thank you! To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular. Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support. For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK. (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have s

That's really useful. This page in particular: https://github.com/bytecodealliance/jco/blob/main/EXAMPLE.md Being able to run "jco wit cowsay.wasm" to see what interfaces that .wasm file provides solves a problem I've run into a bunch of times in the past.

To run a JavaScript interpreter (spidermonkey, in this case) in Wasm, as well as running that same wasm in a JS engine, you want to look at `jco` https://github.com/bytecodealliance/jco The component model tooling is getting very close to maturity and will solve many of these problems.