Wasm can also call web apis directly. The overhead you hear about is in translating complex types like nested dicts etc between formats. But wasm runs inside the js runtime

Depends on what do you mean about by web apis. Fetch API for example is not part of asm.js subset of JavaScript. You going to need a javascript shim on both cases. However, like the siblings comment says: overhead comes from conversion between big structures.

Generating wasm code at runtime is pretty easy (I'd imagine easier than generating valid asm.js code). We have a little library for our tests that handles a lot of it: https://searchfox.org/firefox-main/source/js/src/jit-test/li...

There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it.

https://www.assemblyscript.org/

Just try the asm.js subset and see how it performs for you, I remember that even without the special asm.js support in browsers Emscripten output performance was surprisingly good

It will still work. asm.js is just regular JavaScript code, after all. It just won't parse/run as fast as custom pipeline for asm.js. My guess is that you will not notice much difference unless you have a really huge application.

There are some WAT compilers that are small and fast for running in the browser.

The SpiderMonkey team always had t-shirts made up of these.

OTOH asm.js can be retired now thanks to being backwards compatible with plain JS.

It allowed it to be an experiment that could have been quickly rolled out without a risk of forever lingering as a back-compat requirement for browsers.

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

That is surprising. Do you know the reasons? Is it a special use case or was asm really faster? I find that hard to believe.

Made the requested benchmark:

https://theultdev.github.io/web-sha256-benchmark

https://github.com/TheUltDev/web-sha256-benchmark

It's Chrome wasm (windows) that is slow for me, 2x slower than asmjs.

FF with asmjs optimizations are 2x slower than wasm on FF.

Wasm in FF is 2x faster than wasm in Chrome for this hashing solution (for me).

what's wrong with the built in one?

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...