cheerp-meta VS wizer

Yours is a fair question. I think that, right now, adoption of WebAssembly is quite limited. On the other hand (here at LeanigTech) we are extremely bullish about its potential.

We believe that this technology would be adopted more with better tooling. Our main contribution to this space is Cheerp: A C++-to-WebAssembly _and_ JavaScript compiler (https://github.com/leaningtech/cheerp-meta/). It is designed to seamlessly take advantage of Wasm without sacrificing easy access to Web APIs, all from within C++ with no need of post-processing and glue code.

We know for a fact that amazing products can be build with Cheerp, because we have done it ourselves.

CheerpX is a x86 virtual machine running in the browser, fully written in C++ and compiled with Cheerp. It includes a JIT-compiler that is able to analyze x86 binary code and emit new WebAssembly modules on the fly.

Our most impressive demo yet (WebVM) is available here: https://webvm.io/

A similar project, for WebAssembly so with limited scope is this: https://github.com/bytecodealliance/wizer. And somehow similar but limited on LLVM IR a colleague worked on this for Cheerp (the compiler used here as backend): https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-PreExecuter.

> once by the wasm runtime to compile the rust-python wasm

I'm not sure what you mean by that. The runtime doesn't compile WASM, it simply executes it.

There are tools for dealing with interpreter runtime overhead this by pre-initalizing the environment like Wizer[0]. ComponentizeJS[1] uses it to pre-initialize the Spidermoney engine it packages to gain fast startup times (and you can then prune the initialization only code with wasm-opt). As techniques like ComponentizeJS are also being applied for a specific set of interpreted files, you can even prune parts of the interpreter that would never be used for that specific program. If you want to go even further you could record specific execution profiles and optimize further by those.

[0]: https://github.com/bytecodealliance/wizer

[1]: https://github.com/bytecodealliance/ComponentizeJS

Edge functions are typically run intermittently, with their runtime stopped to free up resources between runs. Therefore a big factor is startup and shutdown speed. Containers are pretty bad there. Deno is better, and WASM is unbeatable, especially with things like Wizer[0].

[0]https://github.com/bytecodealliance/wizer

I imagine startup cost could be amortized by something like wizer: https://github.com/bytecodealliance/wizer

There are security benefits to running each request in its own instance, as it helps prevent accidental leaking of state between requests. To avoid doing lots of expensive initializations, we have a tool called wizer which lets users run their program's initialization once, create a snapshot, and then use that snapshot to do fast startups that don't rerun the whole initialization each time.

See https://github.com/bytecodealliance/wizer for an implementation of this approach.

It should probably be named "Making JavaScript to startup fast on WebAssembly", since the runtime speed is not really improved by the approach they exposed.

Besides that I think Wizer [1] is both an elegant and a simple solution to speed up startup speed with Wasm.

[1] - https://github.com/bytecodealliance/wizer#using-wizer-as-a-l...

A similar project, for WebAssembly so with limited scope is this: https://github.com/bytecodealliance/wizer. And somehow similar but limited on LLVM IR a colleague worked on this for Cheerp (the compiler used here as backend): https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-PreExecuter.