wajic VS component-model

This is a slim alternative to Emscripten which focuses only on the C/C++ <=> JS interoperability part:

https://github.com/schellingb/wajic

There's actually a super interesting project called wajic here:

https://github.com/schellingb/wajic

It's basically clang plus wasm-opt and some magic pixie dust which enables some of the most important features of Emscripten, but without the whole 'technology zoo' :)

There's now an interesting alternative to Emscripten called WaJIC:

https://github.com/schellingb/wajic

Enables most of the "Emscripten magic" (like embedding Javascript code into C/C++ files), but in a more bare bones package (apart from clang it essentially just uses the wasm-opt tool from Binaryen for post-processing).

(to be clear, wajic has fewer out-of-the-box features than Emscripten, but it might be an alternative for very small projects which don't need all the compatibility shims which are coming with Emscripten, while still providing tools for calling between C/C++ and JS.

Since I haven't seen it mentioned in the comments yet, here's another interesting project in the general area of "WASM without Emscripten":

https://github.com/schellingb/wajic

This provides an alternative implementation of Emscripten's EM_JS() magic (embed Javascript snippets right in the C/C++ source code), but without the Emscripten SDK. It still needs some additional tools next to Clang, so it sits somewhere between "pure Clang" and "full Emscripten SDK".

Alas, although there is WebAssembly support in the original dos-like, it is still not supported in the bindings for Rust. It would require a Rust toolchain to integrate with WAjic, which I am pretty much unfamiliar with. If you have any idea on how to achieve this, I would love to know.

The structured concurrency paradigm in workflows is stricter to what I'm reading here [1]. The whole execution model is different from the Task [2], as workflows are transparently unloaded and replayed.

Obelisk has a concept called join sets, where child executions are submitted and awaited. In the future I plan on adding cancellation and allow custom cleanup functions.

[1] https://github.com/WebAssembly/component-model/blob/main/des...

[2] https://github.com/WebAssembly/component-model/blob/main/des...

Although WASIp3 has not yet been released, and the implementations are not yet ready for production use, now is a great time to experiment with it and provide feedback by opening issues on either the spec repo or the wasip3-prototyping repo. Whether you’re developing Wasm components or custom host embeddings to run components, we’d love to have your input. And if you’re a language implementer looking to add concurrency support for Wasm targets, we’d appreciate your input as well.

I am kind of worried that the eagerness for more WASM features may irremediably harm the young ecosystem. Most of what Go added to WASM could be done natively if the component model proposal [1] was merged already.

The standard evolves slowly and as adoption rises we risk having to support more and more non-standard features forever, like WASI and now this.

[1] https://github.com/WebAssembly/component-model

Fully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too.

Bolstering your point -- smart-and-hardworking people are working on this, which results in:

https://github.com/bytecodealliance/componentize-py/

which inspired

https://github.com/WebAssembly/component-model/blob/main/des...

which is made concrete by

https://github.com/dicej/wasi-wheels

The WebAssembly component model is aimed at having composable components that can call each other. The components can be written in any language, compiled to WebAssembly, and interoperate: https://github.com/WebAssembly/component-model/

Extism is a plugin framework for WebAssembly:

https://extism.org/

https://github.com/extism/extism

Visual Studio Code can run WebAssembly extensions: https://code.visualstudio.com/blogs/2024/05/08/wasm

A project to bring WebAssembly plugins to Godot: https://github.com/ashtonmeuser/godot-wasm

WasmEdge can be embedded in applications: https://wasmedge.org/docs/embed/overview

Wasmer can be embedded in applications: https://blog.wasmer.io/executing-webassembly-in-your-rust-ap...

Wasmtime can be embedded in applications: https://docs.wasmtime.dev/lang.html

Eventually by using the component model which will expose the DOM API. It will get to direct wasm to WebIDL calls one day:

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

The component model is being used for the WebAssembly System Interface (WASI):

https://github.com/WebAssembly/WASI/tree/main

In the meantime you can use JavaScript glue code auto-generated by your toolchain to access the DOM. This will be made better with builtins like the js-string-builtins proposal:

https://github.com/WebAssembly/js-string-builtins/blob/main/...

You can call JavaScript functions and DOM methods from wasm like this example from Hoot, which is a Scheme to wasm compiler:

https://spritely.institute/news/building-interactive-web-pag...

Let’s start with writing the interface for our image manipulation component. We’ll define our image manipulation package (using the WIT format) which contains one interface with two image transformations (grayscale and sepia):

For the audience that would be looking to use the WASM Component Model, and not be an infrastructure implementer of it, whether or not they meet some definition of a method, the component model does define things called resources [1] that have "methods". You'll hold a "handle" to it like you would in your own programming language with the expected drop and/or GC semantics (once implemented [2]) because code is generated to access it like any other FFI like C/C++.

With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy.

But I'd agree with a statement saying it is still a long way for general usage.

[1] https://github.com/WebAssembly/component-model/blob/5a34794d...

[2] https://github.com/WebAssembly/gc

[3] https://github.com/bytecodealliance/wasmtime/blob/ba8131c6bf...

[4] https://www.digitalocean.com/community/tutorials/java-classl...