rusty-wacc-viewer
wasmer
rusty-wacc-viewer | wasmer | |
---|---|---|
1 | 131 | |
- | 17,829 | |
- | 1.2% | |
- | 9.9 | |
- | 1 day ago | |
Rust | ||
- | MIT License |
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.
rusty-wacc-viewer
-
Why WebAssembly is innovative even outside the browser
While a "host" application (for the WASM runtime used) is required to enable access to graphical output (or user input) it doesn't have to be a browser.
At the (almost) most basic level a chunk of memory can be used as a framebuffer--the host application would read the pixel data which the WASM bytecode wrote and then write it to the host display via OS-level routines.
There are some plans/experiments at making a framebuffer "device" available as part of WASI.
I've written a couple of graphical WASM host applications that aren't browsers (and which don't use memory for pixel data transfer just integer values returned from a function):
The "WebAssembly Calling Card (WACC) Viewer" is implemented via the Godot game engine and an addon that integrates the Wasmtime WASM runtime with the engine: https://wacc.rancidbacon.com
(Also implemented a WACC Viewer in Rust: https://gitlab.com/RancidBacon/rusty-wacc-viewer)
WACC specifies how to transform three integer values (returned from a function in a WASM module) into a coloured triangle in order to render it on screen.
Another "host application" I implemented was a libretro compatible plugin that loads a WASM module and then feeds the module with input from libretro & retrieves framebuffer pixel data (one pixel at a time :D ) via a WASM function call & writes it to the libretro framebuffer for display.
wasmer
-
Bebop v3: a fast, modern replacement to Protocol Buffers
This is awesome. I'd love to have upstream support in Wasmer ( https://wasmer.io )
-
Unlocking the Power of WebAssembly
WebAssembly is extremely portable. WebAssembly runs on: all major web browsers, V8 runtimes like Node.js, and independent Wasm runtimes like Wasmtime, Lucet, and Wasmer.
-
Show HN: dockerc – Docker image to static executable "compiler"
Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
[0]: https://github.com/ktock/container2wasm
[1]: https://wasmer.io/
- RustPython
-
Howto: WASM runtimes in Docker / Colima
I could not find any guide how to add WASM container capability to Docker running on Colima. This guide provides a few Colima templates for exactly this, which adds WasmEdge, Wasmtime and Wasmer runtime types.
-
Show HN: Mutable.ai – Turn your codebase into a Wiki
Just suggested as well Wasmer on Twitter! https://github.com/wasmerio/wasmer
Looking forward to seeing the results :)
- Jaq – A jq clone focused on correctness, speed, and simplicity
-
Prettier $20k Bounty was Claimed
The Biome team has been incredibly fast on solving the challenge and achieving 95% compatibility with Prettier [1]
Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!
Keep up the great work!!
[1] https://github.com/biomejs/biome/issues/720
[2] https://wasmer.io/
[3] https://wasix.org/
-
The Curse of Docker
It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly.
That's the main reason Wasmer [1] was created :)
[1] https://wasmer.io
-
Bring garbage collected programming languages efficiently to WebAssembly
Thanks for the mention to Wasmer.
I'll put here a link in case is useful for future readers: https://wasmer.io/
What are some alternatives?
hn-search - Hacker News Search
wasmtime - A fast and secure runtime for WebAssembly
cap-std - Capability-oriented version of the Rust standard library
SSVM - WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. It powers serverless apps, embedded functions, microservices, smart contracts, and IoT devices.
Graal - GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
wasm3 - 🚀 A fast WebAssembly interpreter and the most universal WASM runtime
awesome-wasm-runtimes - A list of webassemby runtimes
quickjs-emscripten - Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
godot-wasm-engine
bsnes-plus-wasm - debug-oriented fork of bsnes, with added wasm runtime for scripting
wasm-bindgen - Facilitating high-level interactions between Wasm modules and JavaScript