Comment by eqrion
3 hours ago
> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead
asmjs is going to be strictly more limited in interacting with JS than wasm. You're basically limited to simple number values and array buffers. Whereas wasm now a days has GC types and can hold onto JS value using externref.
> But more important for what i was trying to do, you can't zero copy buffers from js to wasm
I'm pretty sure you can't do that with asmjs either. There is a proposal for zero-copy buffers with wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...
This isn't a fair comparison. Wasm was severely limited when it was first implemented and it had the advantage of a decade of improvements. Asm.js has had zero improvements in that same time frame.
Had WASM not been adopted we would have SIMD in JS ( probably via asm.js) by now. Because we didn't, JS just cannot compete with WASM in many computationally heavy workflows. We'd also have general purpose JS to Asm.js compilation, with few API restrictions, making writing it much easier.
> Asm.js has had zero improvements in that same time frame.
WASM is that evolution of (strict mode) asm.js. The two really aren't all that different from what they can and can't do.
Well, I haven't actually tried the asm.js approach for this, so maybe I'm missing something.
But since asm.js is just (a subset of) javascript, I assumed I could just pass ArrayBuffers around.
With wasm, I could pass a Uint8Array out of it. If I wanted to pass it in, I had to call malloc from the javascript side to allocate in the wasm heap. But since I already had an arraybuffer (from a file upload), that meant an extra copy.
Oh my God. That's so exciting. I did a prototype a while back for writing UDFs in WASM for a query engine. The fact that everything needed to be copied in and out of the environment killed it. Excited to try it again if/when this lands