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

101–110 of 164 posts

Re: Saying goodbye to asm.js

#101

Post by rudi-c »

frumplestlatz wrote: post #89
rudi-c wrote: 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.

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 customers for migrating to Figma.

Re: Saying goodbye to asm.js

#102

Post by rudi-c »

0x457 wrote: post #86
rudi-c wrote: 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 so sad about it? It was just a compilation target that made sense at one point in time. Its like being sad about i386-unknown-freebsd1 being dropped.

Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.

Re: Saying goodbye to asm.js

#103

Post by andrewl-hn »

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…

> Alchemy

Yep, that's the name. There was a brief period in late 2000s when Adobe was pushing hard to make Flash embedded into web ecosystem. They made Air as a way to package Web or Flash code into a desktop app. Essentially it was Electron-before-Electron. Alchemy was a part of this grand plan to be able to integrate existing native libraries with Flash code. The plan was like you said to compile to Flash bytecode, and AFAIK it never went further than a tech demo.

This whole ecosystem turned into a slow train-wreck over approximately 5-year period. Adobe really saw themselves as future stewards of web technology. They donated their ActionScript VM and a JIT to Mozilla and hoped that Firefox would become the first browser with fast JavaScript engine. Google developed Chrome and V8 in secret and managed to release their fast browser early. Microsoft and Yahoo sabotaged adoption of ActionScript dialect as at the next JavaScript. And at the same time Apple went fully anti-plugins, and with the rise of iPhone both Flash and silverlight died off.

Years later Java folks tried to build their own version of Alchemy as part of GraalVM. The project was called Sulong and was using Graal to execute and JIT LLMV bitcode. TruffleRuby was supposed to be a primary early beneficiary to be able to compile and run Ruby native extensions. This was during the period of a race between several JIT solutions in hopes to become "the next Ruby", and Truffle team (along with IBM's OMR) lost the race first to MJIT and then to YJIT. Graal itself seems to loosing steam, because their multi-language VM never got enough adoption among Java, Node, or Ruby people, and the VM itself tended to use too much RAM in era when RAM became premium in the cloud.

Re: Saying goodbye to asm.js

#104

Post by kg »

flohofwoe wrote: post #63
bawolff wrote: post #59

Earlier quoted context omitted.

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

I remember early during the Wasm design process we were openly speculating whether people would eventually figure out how to do stuff like Rowhammer from raw Javascript. My bet was on Yes, but I don't remember if any of my teammates said No. I think we all knew the writing was on the wall by then.

Re: Saying goodbye to asm.js

#105

Post by wmf »

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?

I think the plan was to JIT x86 to other architectures.

Re: Saying goodbye to asm.js

#106

Post by lenkite »

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?

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.

Re: Saying goodbye to asm.js

#107

Post by po1nt »

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?

Memory management is pain. If you want to optimize, you're forced to 4k pages. Runtimes are fragmented. Wasi is a mess. Async and threading is awkward. Whenever you need to integrate with hardware you need platform specific adapters.

In practice, whenever you need more than a singlethreaded app with http/serial port, the "run everywhere" breaks.

Don't get me wrong I love WASM but we're not there yet

Re: Saying goodbye to asm.js

#109

Post by MBCook »

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…

Users still care.

Desktop or collaborative is a false dichotomy. Desktop or performance is too.

I get why you did what you did. It makes sense. But don’t think there aren’t people out here who HATE everything being shoved on the web with no desktop option.

No, electron and PWA don’t count.

Re: Saying goodbye to asm.js

#110

Post by swiftcoder »

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?

WASM standalone runtimes are mostly fine, but WASM in the browser is not great. No direct access to any web APIs (this often really hurts when shuffling data to/from WebGPU). Multithreading via WebWorkers is a complete pain to setup. No zero-copy APIs for streaming data in/out. Little paper cuts, but they all add up...
Post reply on HN