I still maintain the notion we're in the wrong timeline, one where PNaCl died and instead of a worthy, timely successor we end up being boiled alive in a soup of Electron apps.

I really thought, for a time, that we'd be doing everything in the browser. And in a way that's increasingly true, but it all just feels worse than ever. I like WASM and I want to like WASM but the rate of maturity within the ecosystem is incredibly abysmal.

What's worse is that we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox, and companies are selling the reverse: hosted sandboxes, hosted JS-based VMs.

I guess that was always the problem: there was never any money in a client-side sandbox.

You mean Chrome would have pushed it, Apple would have filibustered it by refusing to comment (via lack of investment in the WebKit team), and then gullible folks on the internet would defer to them.

(I will note that Apple seems to have upped WebKit investment this decade since their regulatory problems started in earnest - so it's possible this would end differently today)

I mean that's still basically what they tried to do at the time. They were trying to get them through web standards committees and everything.

IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.

With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.

I re-watch that presentation two or three times a year because it's a great example of how to give a presentation, how to structure your slide deck to complement your presentation, and a surprisingly educational tour of the permission rings architecture of operating systems.

And at some point we're going to have a period or war and our psychological attachments to old programming paradigms will be released so that we can move on to a more advanced way of doing things (but that won't stop your bank from running YavaScript for at least another 85 years).

Don't worry, YavaScript will live forever.

Just substitute asm.js with WASM and you're still on the right track.

If we substituted war with COVID we aren't that far off as both happened in 2020. We still have to wait till 2035 to see if true.

And if not for the rise of AI it's possible that WASM as a machine-level compilation target for all languages might have happened. As much as Gary predicted he didn't see AI coming.

> 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 buffers from js to wasm

I'm pretty sure you can't do that with asmjs either. There is a proposal for zero-copy buffers with wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...

IIRC Emscripten has removed asm.js support around 2020, and that was probably the most important toolchain that ever supported asm.js (maybe followed by Rust, don't know if they still support it though)

> You can't call most web apis from wasm.

You can't from strict asm.js either, since it only supports numbers (no JS strings or objects) and manages the C heap in an ArrayBuffer object just like WASM.

> But more important for what i was trying to do, you can't zero copy buffers from js to wasm.

Same problem as above, you need to call out into "real" Javascript from asm.js and you can't map other ArrayBuffers directly into the 'asm.js heap' either, a copy is needed. The "Javascript FFI" really isn't much different between asm.js and WASM.

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.

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.

To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.

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

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

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

https://www.assemblyscript.org/

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.

Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;)

It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements.

Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).

Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.

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.

How can a subset of JS do "everything" that JS can do?

WASM wont improve if no one adopts it. Its a chicken and egg issue

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.

what's wrong with the built in one?

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