wajic VS memory-control

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.

Apart from WebAssembly modules operating exclusively on scalar input arguments (e.g., computing the sine of a single number), every WebAssembly module instance must be associated with WebAssembly memory, which is allocated in fixed increments of 64KiB (i.e., a "page"). And importantly, as of this blog post, WebAssembly memory can only grow and never shrink. As there is currently no mechanism for releasing memory to a host, a WebAssembly application's memory footprint can only increase. These two aspects combined increase the likelihood of allocating memory which is never used and the prevalence of memory leaks.

Indeed, webassembly is moving extremely slowly. I started a project years ago expecting https://github.com/WebAssembly/memory-control/blob/main/prop... and https://github.com/WebAssembly/memory64 to be fixed at some point. Neither are yet, and the project still suffers from it to this day.

I think wasm is still great without these fixes, but I have lost confidence in the idea that wasm will reach its full potential any time soon.

Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection.

But researching it a bit I found this issue, so it clearly seems to be a problem for a bunch of people out there. And apparently both V8 and Spidermonkey have already addressed this quite recently, see this issue.

FWIW there is a proposal in the works to add page-based protection, which will allow unmapping the 0 page, restoring the trap-on-null-deref behavior that is important for many languages with safety checks.

https://github.com/WebAssembly/memory-control