WASM development is really for a "level lower" than HTML, CSS, and JavaScript development. I know this because, being curious about it myself, I tried a year ago to make use of a WASM runtime in Go to run a piece of WASM code (I think I wrote something in V and compiled it to WASM).

It becomes a huge pain in the bum as soon as you have to deal with moving anything more than trivial types around, because you have to manually allocate memory for the WASM runtime and move bytes around. The byte representation needs to be understandable by the source language for your WASM code (the v language in my case). This is why these WASM runtimes use ints in their README examples, it would look and be horrendously complex otherwise.

If one is looking to use WASM for something for plugin development in the backend, I would try and look for something that is not WASM generic, but works with the source language, and where the WASM aspect is an under-the-hood detail.

This is the same in any system where you have two different runtimes/programming languages. The source values need to be serialized to bytes and then deserialized by the target. You could use json for this or flatbuffers. WASI has its own serialization mechanism but I don't know what langugages it supports.

I'm working with Extism at the moment, It's pretty nice at handling the memory allocations.

I'm not sure how well it carries over to embedded platforms though, but I'm really interested in trying.