Would be sweet if I can have a static #HTML / #CSS website that uses #HTMX for interaction with a backend written in Kotlin and compiled to #wasm running on an edge location using #wasi .
> I mean, you get problems if you try to launch a thread…
Which specific problems are you refering to?
As far as I understand, you can spawn threads in JS environments (e.g. in the browser) with no problems (using Web Workers and SharedArrayBuffer under the hood).
Only spawning them in non-JS environments is currently not supported, if I'm not mistaken. For this, we'll need the thread-spawn proposal implemented, right!?
I think with #wasi 0.2 out, #wasmcloud 1.0 just released, and the huge push for #federation right now, it would be a perfect time for someone to create an ActivityPub/ActivityStreams WASI proposal and get a Mastadon server compiling to Wasm.
Warren Dujardin just put out a prototype of #webassembly#wasi:usb: https://github.com/Wadu436/usb-wasm. Give it a look; there are a bunch of funky issues around this area in IoT, but I love seeing these PoCs.
I'm very excited about the future of webassembly and wasi preview 2.0. I compiled my Rust/C++ crate femark into a wasi component, and used it to make an editor with live preview and syntax highlighting for Leptos #rust#leptos#wasi#web#webassembly
I made a sketch of an Embedded API in the WebAssembly Interface Types (Wit) IDL, covering GPIO, I²C, SPI, PWM, and delays, based on the embedded-hal API, to show what such a thing might look like:
The magic of #WebAssembly and #WASI is that as long as you can feed your target program to a runtime capable of understanding it, everything else just kinda works, because it's already expressed on the far side of the abstraction boundary.
I have not written a line of #Rust before, but I was able to slightly tweak one of the #wasmtime examples to get the CPython WASI build running for the most basic task.