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

111–120 of 164 posts

Re: Saying goodbye to asm.js

#111

Post by wffurr »

xg15 wrote: post #96
flohofwoe wrote: post #57

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

Re: Saying goodbye to asm.js

#112

Post by andrewl-hn »

I remember when Mozilla released OdinMonkey that was hyper-specialized for asm.js code, the Chrome / V8 team instead worked on general-purpose optimizations in their JIT that would run normal JavaScript faster but also would help asm.js. The difference in speed was 2-4x in favor of Firefox, and they hyped it a lot :D

Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.

Re: Saying goodbye to asm.js

#113

Post by mccr8 »

tardedmeme wrote: post #50
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 are the key differences between PNaCl and WASM?

One of the big issues with NaCl is that the API it used wasn't standardized at all and there was only a single implementation. You could pick a random function and ask "hey, what happens if you pass in some slightly weird arguments?" and there was no answer beyond "whatever Chrome does". With enough work, maybe that could have been overcome while preserving backwards compatibility, but there were lots of random functions in there because somebody or other had found it useful. WASM was built from the ground up with a standards process and multiple implementations.

Re: Saying goodbye to asm.js

#114

Post by mccr8 »

lmkg wrote: post #55
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 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.

Re: Saying goodbye to asm.js

#115

Post by trgn »

:(

this was such a crazy project. remember when we compiled our c++ to wasm over 10 years ago, wait, this works?! web seemed to move so fast then.

Re: Saying goodbye to asm.js

#116

Post by karel-3d »

What I liked about asm.js is that it's "just" javascript and you don't need any special way to load them, while with wasm you have the wasm file which you need to load on the side, which is a bit clunkier. But eh it's a tiny thing

Re: Saying goodbye to asm.js

#117

Post by braden-lk »

rudi-c wrote: post #101
frumplestlatz wrote: post #89

Earlier quoted context omitted.

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

This is a lazy statement based on extremely vague handwaving about desktop v.s. web. It's not the 2010s anymore. Time to drop these generalities. Users were migrating to us _from_ desktop applications. Collaboration was the key differentiator, but a less well known reason was that improved performance, including but not limited to the support of large design systems, was also a commonly cited reason among paying cust…

How dare you make a performant, accessible app that's easy to distribute, instead of spinning up a different eng. team to maintain a different codebase on a different deployment pipeline so 1% of your userbase can say it's a "real" desktop app instead of a silly "fake" desktop app. :P

Jokes aside, Figma's stack is super inspiring, and y'all's articles on sync engines heavily inspired my work on LegendKeeper. I appreciate the work you do!

Re: Saying goodbye to asm.js

#118

Post by jorvi »

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…

Heh, emscripten. I remember running the Unreal engine in the browser with that. Quite impressive indeed.

Re: Saying goodbye to asm.js

#119

Post by pjmlp »

jcranmer wrote: post #88
Randomno wrote: post #82

Earlier quoted context omitted.

The P in PNaCl is Portable. Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.

The most common plugins were Flash, Silverlight, Adobe Reader, and the Java applet plugin, and I think all of those were in mildly common use when plugins were on their last legs.

Now you can have all of them running on top of WebAssembly, companies even pay for support.
Post reply on HN