Live data from Hacker News

Saying goodbye to asm.js

spidermonkey.dev

121–130 of 164 posts

Re: Saying goodbye to asm.js

#121
post #27

> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.

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 inc…

PNaCl was a terrible idea. It was as bad of an idea as shipping the raw sqlite interface in the browser.

I feel like some of the Google-sourced standards are the laziest, least-webby ones out there. There are some good ones that come from the Chrome team, but man the real stinkers are _always_ a lazy Google engineer trying to ship a half-baked clone of something native in the browser because they need it for something or other internally.

Re: Saying goodbye to asm.js

#122

Earlier quoted context omitted.

What do you feel is immature in the WASM ecosystem right now?

Kindly give us performant access to the DOM, pretty-please! WITHOUT any JS glue code. WASM is called WEB assembly but it can't access the Web API's without paying tax to the JS tyrant in between.

> Kindly give us performant access to the DOM, pretty-please! WITHOUT any JS glue code.

https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Re: Saying goodbye to asm.js

#123
post #114
post #55

Earlier quoted context omitted.

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.

The cute thing about asm.js is that it was fully backwards compatible with the web: it was just a lot slower without dedicated support. So Epic or whomever could put out a demo that would run just fine in Chrome, but the performance was a lot worse than Firefox which had a dedicated compilation pipeline, so it made Chrome look bad.

Exactly. "You can't not support it; you can only be slow."

Re: Saying goodbye to asm.js

#124
post #31

That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).

What’s sad about that is we could have had a clean, native, desktop Figma application.

A native application that further locks users into some single platform? Or accept all the maintenance and development costs and burdens that keep the application one step behind Photoshop if they wanted to support multiple platforms?

Re: Saying goodbye to asm.js

#126
post #31

That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).

What’s sad about that is we could have had a clean, native, desktop Figma application.

They explicitly had the goal of being a web application. It was a product choice, not a technical choice.

Re: Saying goodbye to asm.js

#127
post #111
post #96

Earlier quoted context omitted.

> The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox). Out of curiosity, does that mean that NaCL (without P) only ran on x86? Or were there different subsets for different architectures?

You could compile NaCL code for x86_64, aarch64, and aarch32 as well. Chrome apps has a system similar to mobile apps where you would upload an app with all binaries and users would get the one for their system architecture.

Ah, that makes sense. So users were effectively cross-compiling the NaCL binaries for multiple architectures.

Re: Saying goodbye to asm.js

#128
post #27

> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.

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 inc…

I’ve found canvas + WebAssembly works great together!

Here’s an example of Sudoku running in WebAssembly (it was vibe coded in Zig) and then rendered to canvas. The interface between the wasm module and the browser is function calls for keyboard and mouse events, and then another that renders to a pixel buffer to copy to the canvas.

https://qip.dev/play-sudoku

And this approach also works for simple forms, such as a URL input that gets turned into a QR code. Again the interface is simple, here converted a URL into SVG markup. As you type in the input we call the WebAssembly render function again.

https://qip.dev/qr

Re: Saying goodbye to asm.js

#129
post #51
post #24

Earlier quoted context omitted.

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.

Not really: ASM.js became WASM. What killed the possibility of WASM being The One Way to run everything is AI... the one wildcard that Gard Bernhardt didn't predict.

To be honest, with how bad a target WASM is for any existing compiler, I feel like what killed that possibility was WASM itself.

Its IR design is horrendeous.

Re: Saying goodbye to asm.js

#130
post #65

Earlier quoted context omitted.

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 inc…

I do understand why NaCL and PNaCL are undesirable and why wasm is much better, but as a student the NaCL ssh app had saved my computer science homeworks more than once, and this is something that still doesn't have an alternative although I rarely would need it nowadays.

https://ssheasy.com/

https://www.google.com/search?q=wasm+ssh+client

...the future is here!

Post reply on HN