Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saying goodbye to asm.js

spidermonkey.dev

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Saying goodbye to asm.js

#91

Post by pornel »

Rohansi wrote: post #56
chilmers wrote: post #35

Earlier quoted context omitted.

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.

Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code

You can't mix them. It won't pass validation, and will fail to be optimized as asm.js.

In asm.js you have to treat JS functions and objects as special extern values, just like in WASM.

asm.js - when validated and optimized - is closer to WASM serialized to a JS-like syntax than actual JS.

Re: Saying goodbye to asm.js

#92

Post by pornel »

unconed wrote: post #17

Asm.js was never needed as a legacy mechanism, as it was just a compilation target for native code. There was nothing that it needed to remain backwards compatible with, all asm.js code was new code. https://acko.net/blog/on-asmjs/

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.

Re: Saying goodbye to asm.js

#93

Post by chilmers »

Rohansi wrote: post #56
chilmers wrote: post #35

Earlier quoted context omitted.

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.

Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code

I don't think that is true though. The spec make it clear that it only has access to a limited subset of the JS standard libraries and specially registered foreign functions:

> An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data:

> - a standard library object, providing access to a limited subset of the JavaScript standard libraries;

> - a foreign function interface (FFI), providing access to custom external JavaScript functions; and

> - a heap buffer, providing a single ArrayBuffer to act as the asm.js heap.

From http://asmjs.org/spec/latest/#introduction:~:text=External%2...

Re: Saying goodbye to asm.js

#94

Post by projektfu »

xyzzy_plugh wrote: post #41
pjmlp wrote: 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 wish we had another alternate timeline.

"Our submission is in TALx86, a strongly typed functional language that encourages an explicit continuation-passing style and supports mutually recursive modules. We were encouraged to use this language when we learned that the competition would allow us to run our program on an interpreter implemented in hardware. We are grateful to the Intel Corporation for developing this interpreter."

https://www.cs.cornell.edu/talc/icfp99-contest/solution.htm

Re: Saying goodbye to asm.js

#95

Post by kettlecorn »

xyzzy_plugh wrote: post #41
pjmlp wrote: 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…

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

Re: Saying goodbye to asm.js

#96

Post by xg15 »

flohofwoe wrote: post #57
tardedmeme wrote: post #50

Earlier quoted context omitted.

What are the key differences between PNaCl and WASM?

There were 3 systems, all with interesting differences. 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). The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately w…

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

Re: Saying goodbye to asm.js

#98

Post by jauntywundrkind »

kettlecorn wrote: post #95
xyzzy_plugh wrote: post #41

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…

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

Not the previous poster, but immatures: Needing to compile down to one enormous program, with no possible code sharing. The async story is not good.

Wasm components & wasi have a lot of promise here. Until now though browsers have been ignoring all this; Firefox just started taking a more active interest. https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Re: Saying goodbye to asm.js

#99

Post by titzer »

pjmlp wrote: post #90
flohofwoe wrote: post #53

Earlier quoted context omitted.

WASM has been adopted and it has improved massively since 2017 though.

Yes, but GC is still useless for languages with interior pointers, some features require gimmicks with server configuration, and for most languages we aren't any way closer to -march=wasm and that's all. We still need to download half Internet for emscripten, plus whatever tools are being used on top. Although it is somewhat simpler for those that build on top of binaren.

Wasm evolution happens in fits and starts. There's a lot of nested chicken-and-egg problems. We first started on Wasm GC less than two years after MVP, and then we didn't have any language targeting it, so we had to bootstrap it. Now, Java, Dart, Kotlin, and Scala all target Wasm GC (and Virgil too :-)). The interior pointer is on people's radar.

The next big feature coming is stack switching. It works best with unboxed continuations, which necessitates a fat pointer representation in the engine. Once the engine supports fat pointers, then interior pointers will be an easier sell. It might take several years to get there, but Wasm evolves slowly and deliberately, and IMO hasn't made any massive fatal design errors yet.

Re: Saying goodbye to asm.js

#100

Post by doctorpangloss »

xyzzy_plugh wrote: post #41
pjmlp wrote: 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…

> we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox

The DevOps infrastructure Kubernetes runbook AI inference router API people (DIK-AROUnders for short) always want an abstract technical solution that increases both their budget and their distance from the end user's actual application. Like the more money they get to dick around with meaningless technical cathedrals, the better. They're only bent out of shape that they couldn't parlay that into a sweet crypto scheme. In the real world, the line between what users actually want and what DIK-AROUnders call inauthentic activity is quite blurred.

To me, the fact that AI agents can browse websites and make payments and read my email and pretend to be me or other people is a huge part of their value proposition. People want to get out of the sandbox! There are many meanings to the words security and privacy.

Post reply on HN