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

yeah turns out it was chrome that was slow, not firefox.

wasm hashing in chrome is half the speed of firefox for me.

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

Don't worry, YavaScript will live forever.

In Germany, it's still not uncommon to hear Yava and YavaScript.

I understand that Jawohl is still quite popular there, but JawohlScript adoption is sadly lagging.

It's the only pronunciation you'll hear in Iceland

I still refer to it as YavaScript much to the confusion of junior devs. I just tell the new kids: "you had to be there..."

Even a quick glance at the bugs revealed in the blog post would quickly disprove your theory.

I can only speak for SpiderMonkey, as that’s the team I’m on, but we humans are definitely writing and reviewing the patches for these bugs. Sometimes the AI suggestions are good, often they’re not, and we never send off a fix for a security bug unless we thoroughly understand the problem and have assessed its severity ourselves.

You can already make apps that write directly to a canvas today, and almost nobody does because they want what the DOM provides for them. Wasm changes nothing about the APIs available to web apps.

The “single array of memory” is not the problem; that’s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/prop...

A lot of the time I think you just won’t want to use multiple components. It’s nice to be able to compose them together, I guess, but in general it seems to me that a toolchain will typically just want to generate a single big component so that everything can interact without limits internally.

This is not strictly true; there are synchronous APIs for compiling Wasm (`new WebAssembly.Module()` and `new WebAssembly.Instance()`) and you can directly embed the bytecode in your source file using a typed array or base64-encoded string. Of course, this is not as pleasant as simply importing a module :)

As someone on the SpiderMonkey team who had to evaluate some of Anthropic's bugs, I can definitely say that Anthropic's test cases were definitely far easier to assess than those generated by traditional fuzzers. Instead of extremely random and mostly superfluous gibberish, we received test cases that actually resembled a coherent program.

> I don't think making it a DOM controller is where the action is

Why not? I feel like people have gotten so used to the limitations of WebAssembly today that they've internalized JS as the only answer. But I don't really like JS, and would love to build web apps in other languages, and I totally would if it wasn't a huge pain (and slower too!)