That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).
Saying goodbye to asm.js
31–40 of 164 posts
Re: Saying goodbye to asm.js
#32We'll drink again in Valhalla (not the JDK project, the one with much carousing).
Re: Saying goodbye to asm.js
#33Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
[1]: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
Re: Saying goodbye to asm.js
#34asm.js is faster than WASM, and it can do everything that JS can do.
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
Re: Saying goodbye to asm.js
#35I 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 ze…
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.
Re: Saying goodbye to asm.js
#36asm.js is faster than WASM, and it can do everything that JS can do.
How can a subset of JS do "everything" that JS can do?
Re: Saying goodbye to asm.js
#37Hmmm, need a asm.js -> WASM transpiler maybe. (compiling legacy code with legacy versions of Emscripten is quite frustrating, almost as bad as updating your JS code to be compatible with accumulated changes in the Emscripten ABI)
Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts disabled, but it would be nice to have a translator.
Re: Saying goodbye to asm.js
#38asm.js is faster than WASM, and it can do everything that JS can do.
WASM wont improve if no one adopts it. Its a chicken and egg issue
Re: Saying goodbye to asm.js
#39I 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 ze…
> 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…
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.
Re: Saying goodbye to asm.js
#40asm.js is faster than WASM, and it can do everything that JS can do.
Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome. I don't think Chrome ever did an asm.js specific optimization.
It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...