wasm-by-example
cargo-component
wasm-by-example | cargo-component | |
---|---|---|
1 | 2 | |
484 | 405 | |
- | 8.6% | |
0.0 | 8.7 | |
about 2 months ago | 4 days ago | |
JavaScript | Rust | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wasm-by-example
-
WASM by Example
Looks like the code is here if you want to send a PR: https://github.com/torch2424/wasm-by-example
cargo-component
-
WASM by Example
well, for starters, wasm is sandboxed. So, if a wasm library needs an import (eg: read/write filesystem), it has to be explicitly provided. It cannot do anything except math by default. This allows host a high amount of control.
different wasm libraries can have separate memories. So, if a library X depends on a jpeg decoder library, the host has to provide that as import. The jpeg decoder library might export a fn called "decode" which takes an array of bytes of a jpeg, and returns an Image struct with rgba pixels. This allows the "memory" of the two libraries to be separate. the jpeg decoder cannot "write" to the X's memory, cleanly separating the two of them.
Wasm component model recognizes higher level objects called resources, which can be shared between libraries (components). This allows X to simply pass a file descriptor to jpeg decode fn, and the sandbox model makes sure that jpeg library can read from that file only and the rest of the filesystem is still offlimits. wasm is already getting support for garbage collector. So, a high level language can just rely on wasm's GC and avoid shipping its entire runtime. Or the host can guarantee that all the imports a language needs will be provided, so that the language libraries can shed as much runtime weight as possible.
Finally, Component model is designed from ground up to be modular, which allows imports/exports/namespaces and other such modern features. C.. well, only has headers and usually brings a lot of backwards compatibility baggage. The tooling (eg: wit-bindgen) will provide higher level support like generating code for different language bindings by taking a wit (header for wasm) declaration file. If you are familiar with rust, then https://github.com/bytecodealliance/cargo-component#getting-... shows how easy it is to safely create (or bind to) wasm bindings
-
Using WASM for a plugin system in Rust? (generate code at runtime and then hot reloading it as a library)
Yes, wasm_bindgen is js only. At least for now, in future I would also expect it to migrate to component model. There is also cargo-component which is a way to create modules compatible with component model. You define your module interface in WIT and your dependencies on other wasm modules in the similar way you would define crate dependencies. Alternately there is wit-bindgen that is a codegen tool for multiple languages that also accepts WIT as input.
What are some alternatives?
dotnet-pdk - Extism Plug-in Development Kit (PDK) for C# and F#
cxx-wasm-freestanding - example of a c++ -> wasm build that doesn't use emscripten or any standard library
dcraw - Mirror of Dave Coffin's dcraw, with full history
extism - The framework for building with WebAssembly (wasm). Easily load wasm modules, move data, call functions, and build extensible apps.
component-model - Repository for design and specification of the Component Model
scale - A framework for building high-performance plugin systems into any application, powered by WebAssembly.
wasmtime - A fast and secure runtime for WebAssembly
jco - JavaScript tooling for working with WebAssembly Components
wit-bindgen - A language binding generator for WebAssembly interface types
workers-wasi
wazero - wazero: the zero dependency WebAssembly runtime for Go developers