Yes, you can use the component model (and other tooling like WIT) without using WASI.

Yes, the component model is a standard developed under the umbrella of the W3C's WebAssembly Community Group.

That said, while it is relatively stable and hasn't changed much in the last year or so, the component model has not graduated through all the phases of the standardization process yet. It doesn't, for example, have a formal specification yet, although its canonical ABI does have a reference implementation in Python.

https://github.com/WebAssembly/component-model/

There is a section in the linked announcement titled "Why use a WebAssembly Runtime?" that hopefully answers your question.

It doesn't say why one should use this WebAssembly implementation, and not (for example) the V8-based implementation that comes with Node.js.

I wrote a (very surface level) comparison on this last year[1]. If you already have V8 in your environment, it's probably worth using V8, but if you just want to load a wasm interpreter into some Rust code, wasmtime is a much nicer interface to work with and more lightweight.

[1] https://paulbutler.org/2021/calling-webassembly-from-rust/

(nb. if I were to write this post today, it would be an omission not to mention the component model)

Both Wasmtime and Lucet can AOT compile Wasm, for what it's worth.

WAVM can also compile WebAssembly code to an optimized, native object file.

It can also embed the compiled code into the WebAssembly module, so that the same module can directly run the precompiled code (when using WAVM) or be executed as a standard module by another runtime.

TIL! Lucet is being switched over to Wasmtime as well [1]. I'll have to take another look at it.

[1] https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...

There is a DOM story: host bindings. It just isn't implemented yet.

However, that doesn't mean that you can't use it now. wasm-bindgen is essentially a polyfill for host bindings plus some other little things.

Some resources to check out if you want to learn more:

* Host bindings: https://github.com/WebAssembly/host-bindings/blob/master/pro...

* More info about web-sys (web-sys is like the raw libc for the web): https://rustwasm.github.io/wasm-bindgen/web-sys/index.html

* API documentation for web-sys: https://docs.rs/web-sys/0.3.2/web_sys/

* DOM hello world example: https://rustwasm.github.io/wasm-bindgen/examples/dom.html

* A mini MS Paint style example: https://rustwasm.github.io/wasm-bindgen/examples/paint.html

* An FM synth in WebAudio: https://rustwasm.github.io/wasm-bindgen/examples/web-audio.h...

GNU libiberty includes a Rust symbol demangler that you can link: https://github.com/gcc-mirror/gcc/blob/master/libiberty/rust...

Great catch -- thanks for reporting this!

Fix is over in https://github.com/fitzgen/source-map-mappings/pull/15

Thanks for the heads up. It used to be a `thread_local!`, but switching to a `static mut` resulted in smaller code size. I just forgot to update the code snippet in the article.

> which IIRC requires unsafe access as it's not thread-safe

Yes, and also has no guarantees against mutably aliasing and re-entry.

Note that wasm currently has no shared memory threading (just message passing via FFI through JS and workers), so thread-safety isn't an issue to be wary of here, just re-entry.

Thanks for the report!

We've already fixed some of these issues[0] but I didn't update the code snippets in the article -- woops!

[0] https://github.com/tromey/vlq/commit/3b41a2b6c778ce476eaaa28...

.eh_frame is DWARF with a couple tiny tweaks

Right, but it's an allocated section that doesn't get stripped like debuginfo.

There is some discussion about power usage in this video by Jack Moffit: https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...