I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK.

But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead.

But I wasn't sure that emscripten still fully supported it.

You can't call most web apis from wasm.

But more important for what i was trying to do, you can't zero copy buffers from js to wasm.

Everything is a trade off. The isolation is a good thing, but also a bad thing.

▲

eqrion 5 hours ago | parent | next [-]

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

▲

davidmurdoch 5 hours ago | parent | next [-]

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.

▲

flohofwoe 5 hours ago | parent [-]

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

	▲	4 hours ago \| parent [-]
		[deleted]

▲

looneysquash 3 hours ago | parent | prev | next [-]

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.

▲

stusmall 4 hours ago | parent | prev [-]

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

▲

flohofwoe 5 hours ago | parent | prev | next [-]

IIRC Emscripten has removed asm.js support around 2020, and that was probably the most important toolchain that ever supported asm.js (maybe followed by Rust, don't know if they still support it though)

> You can't call most web apis from wasm.

You can't from strict asm.js either, since it only supports numbers (no JS strings or objects) and manages the C heap in an ArrayBuffer object just like WASM.

> But more important for what i was trying to do, you can't zero copy buffers from js to wasm.

Same problem as above, you need to call out into "real" Javascript from asm.js and you can't map other ArrayBuffers directly into the 'asm.js heap' either, a copy is needed. The "Javascript FFI" really isn't much different between asm.js and WASM.

▲

chilmers 5 hours ago | parent | prev [-]

Perhaps I'm misunderstanding, but doesn't asm.js have the same restrictions? I.e. you can't call web APIs directly from asm.js code, you still need special handling for "foreign" functions.

▲

Rohansi 4 hours ago | parent [-]

Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code

	▲	flohofwoe 4 hours ago \| parent \| next [-]
		> so you should be able to mix them AFAIK as soon as you'd start mixing idiomatic JS and asm.js, you lose the "special sauce", you only got the special asm.js treatment in browsers when putting a "use asm" at the top of a source file, and that would prevent using regular JS features in the same file.
	▲	chilmers 2 hours ago \| parent \| prev \| next [-]
		I don't think that is true though. The spec make it clear that it only has access to a limited subset of the JS standard libraries and specially registered foreign functions: > An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data: > - a standard library object, providing access to a limited subset of the JavaScript standard libraries; > - a foreign function interface (FFI), providing access to custom external JavaScript functions; and > - a heap buffer, providing a single ArrayBuffer to act as the asm.js heap. From http://asmjs.org/spec/latest/#introduction:~:text=External%2...
	▲	pornel 2 hours ago \| parent \| prev [-]
		You can't mix them. It won't pass validation, and will fail to be optimized as asm.js. In asm.js you have to treat JS functions and objects as special extern values, just like in WASM. asm.js - when validated and optimized - is closer to WASM serialized to a JS-like syntax than actual JS.