upvote
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.

reply
> 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.

reply
deleted
reply
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.

reply
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
reply