Live data from Hacker News

Saying goodbye to asm.js

spidermonkey.dev

61–70 of 164 posts

Re: Saying goodbye to asm.js

#61
post #56

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

> so you should be able to mix them

AFAIK as soon as you'd start mixing idiomatic JS and asm.js, you lose the "special sauce", you only got the special asm.js treatment in browsers when putting a "use asm" at the top of a source file, and that would prevent using regular JS features in the same file.

Re: Saying goodbye to asm.js

#62
post #26

I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK. But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead. But I wasn't sure that emscripten still fully supported it. You can't call most web apis from wasm. But more important for what i was trying to do, you can't ze…

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

Oh my God. That's so exciting. I did a prototype a while back for writing UDFs in WASM for a query engine. The fact that everything needed to be copied in and out of the environment killed it. Excited to try it again if/when this lands

Re: Saying goodbye to asm.js

#63
post #59

Earlier quoted context omitted.

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 only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement). Presumably that is because PNaCl predated spectre (?)

Indeed, NaCl and PNaCl would have been hit by Meltdown/Spectre at least as badly as SharedArrayBuffer.

Re: Saying goodbye to asm.js

#64
post #55
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 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 big difference was that they lacked the market share they enjoy nowadays, with their forks and Electron crap.

Re: Saying goodbye to asm.js

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

Re: Saying goodbye to asm.js

#66

Earlier quoted context omitted.

This isn't a fair comparison. Wasm was severely limited when it was first implemented and it had the advantage of a decade of improvements. Asm.js has had zero improvements in that same time frame. Had WASM not been adopted we would have SIMD in JS ( probably via asm.js) by now. Because we didn't, JS just cannot compete with WASM in many computationally heavy workflows. We'd also have general purpose JS to Asm.js com…

> Asm.js has had zero improvements in that same time frame. WASM is that evolution of (strict mode) asm.js. The two really aren't all that different from what they can and can't do.

[deleted]

Re: Saying goodbye to asm.js

#67
post #3

Never saw those monkey prints before https://monkeyink.com/ink/blog/archives/2016/08/_this_is_a_f... "The image is a collage of antique open source art reflecting the open source code."

The SpiderMonkey team always had t-shirts made up of these.

Re: Saying goodbye to asm.js

#68
post #24
post #15

So the death of asm.js is upon us? We are drifting away from the timeline of the prophecy: https://www.destroyallsoftware.com/talks/the-birth-and-death... (And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)

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.

Yagrum Bagarn has something for you.

Re: Saying goodbye to asm.js

#69
post #15

So the death of asm.js is upon us? We are drifting away from the timeline of the prophecy: https://www.destroyallsoftware.com/talks/the-birth-and-death... (And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)

Don't worry, YavaScript will live forever.

In Germany, it's still not uncommon to hear Yava and YavaScript.
Post reply on HN