Mozilla's SpiderMonkey team blogs about Firefox's JavaScript and WebAssembly engine, covering compiler work, newsletters and new feature shipping.
HN commenters cite it for the Memory64 post showing wasm64 can run 10% to over 100% slower, and for details on asm.js compilation.
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-actually-worth-using.html
> WebAssembly apps tend to run slower in 64-bit mode than they do in 32-bit mode. This performance penalty depends on the workload, but it can range from just 10% to over 100%—a 2x slowdown just from changing your pointer size.
> This is not simply due to a lack of optimization. Instead, the performance of Memory64 is restricted by hardware, operating systems, and the design of WebAssembly itself.
https://spidermonkey.dev/blog/2025/01/15/is-memory64-actually-worth-using.html
This is probably referring to some work to use Stencil for self-hosted code. That reduced process overhead by 6%, which is quite a bit: https://bugzilla.mozilla.org/show_bug.cgi?id=1688794
There might have been some other Stencil work that landed in 92 to reduce memory.
There's a description of what Stencil is, and some work related to it that landed in Firefox 90 and 91, here: https://spidermonkey.dev/blog/2021/07/19/newsletter-firefox-90-91.html
I already posted the link in another reply, but this is a good overview why wasm32 is usually the better choice over wasm64:
https://spidermonkey.dev/blog/2025/01/15/is-memory64-actually-worth-using.html
TL;DR: wasm64 has slower memory load/store operation because it requires 'software bounds checking', so unless you absolutely need more than 4 GB RAM, wasm32 is the better choice.
Spidermonkey is quite embeddable by itself [1]. On Linux things like polkit, couchdb, mongodb use it. Still, the compilation process seems to download the whole firefox tarball and only compiles the JS related parts [2, 3].
[1] https://spidermonkey.dev
[2] https://archlinux.org/packages/extra/x86_64/js78/
[3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78.html
An example: “Are We ESMified Yet?” is a Mozilla dashboard tracking an incremental Firefox code migration (1.5 years and counting) from a Mozilla-specific "JSM" JavaScript module system to the standard ECMAScript Module "ESM" system. Current ESMification: 96.69%.
“Are We X Yet?” is a Mozilla meme for dashboards like this.
https://spidermonkey.dev/areweesmifiedyet/