I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?
Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?
So basically wasm is some optimisation. That's fine but it's not something groundbreaking.
And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.
That's underselling it a bit IMO. There's a reason asm.js was abandoned.
And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then.
Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser.
The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark.
Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.