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

151–160 of 164 posts

Re: Saying goodbye to asm.js

#151

Post by avadodin »

nextaccountic wrote: post #140
DarkUranium wrote: post #129

Earlier quoted context omitted.

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.

Can you talk more? I've seen people say only good things about wasm

Not op, but I only know it as the 32-bit single-threaded binary replacement for JavaScript that can't interact with anything naturally yet people get all excited about when they manage to turn their LLVM slop output into it.

Maybe we've been reading different HN submissions.

Re: Saying goodbye to asm.js

#152

Post by pjmlp »

andrewl-hn wrote: post #103
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…

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

Graal was never designed as OpenJDK replacement, it is the evolution of MaximeVM, and their main customers, meaning who pays the team salaries are the Oracle database and cloud teams.

In that regard they are doing pretty well.

Plus all the folks that never paid for ExcelsiorJET, JRockit, PTC, Aicas, and many others of which only PTC and Aicas survive, now have in Graal their gratis AOT compiler.

Alongside OpenJ9 (which is more like what Leyden is trying to be), and the one on the box shipped alongside ART.

Ruby on top of JVM has a few interwined stories since the days Sun embraced it on Netbeans, and it suffers from the same issues as PyPy regarding adoption, it suffices not to be 100% compatible with whatever crazy extensions written in C exist out there.

Microsoft was probably more clever giving up on IronPython and IronRuby, and keeping the DLR infrastructure.

Re: Saying goodbye to asm.js

#153

Post by flohofwoe »

jauntywundrkind wrote: post #98
kettlecorn wrote: post #95

Earlier quoted context omitted.

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

Probably an unpopular opinion, but IMHO the WASM Component Model is an entirely overengineered boondoggle that has no place in browsers.

It's trivial to create small statically linked WASM programs in the "a few dozen kilobytes" range with the right programming language (like C).

"Code sharing" via dynamic linking also works, but it has the same downsides as dynamic linking on native platforms (basically that DLL interfaces represent an optimization barrier): https://emscripten.org/docs/compiling/Dynamic-Linking.html

Re: Saying goodbye to asm.js

#154

Post by esperent »

xscott wrote: post #83
chamomeal wrote: post #72

Earlier quoted context omitted.

wait how did AI impede wasm?

I believe the idea is that you don't care what language is being used if you aren't going to look at it anyway. Given that premise, the AI can write JavaScript instead of something you need to compile separately.

WASM is hard enough to use that I would say the number of people using it just because they don't like JS/TS is fairly small.

At least that's always been my impression. If you're willing to go through the effort to use it, it's probably because you need the performance gains, and AI hasn't changed that.

Re: Saying goodbye to asm.js

#155

Post by binsquare »

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 care about it more than money, here's my take on a client-side `sandbox`: https://github.com/smol-machines/smolvm

it's a lightweight vm because i see sandboxing as a feature of vm's.

Re: Saying goodbye to asm.js

#156

Post by projektfu »

nextaccountic wrote: post #139
projektfu wrote: post #94

Earlier quoted context omitted.

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…

Isn't this approximately just wasm?

Is there hardware that executes WASM directly?

Re: Saying goodbye to asm.js

#157

Post by p_l »

pjmlp wrote: post #152
andrewl-hn wrote: post #103

Earlier quoted context omitted.

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

Graal was never designed as OpenJDK replacement, it is the evolution of MaximeVM, and their main customers, meaning who pays the team salaries are the Oracle database and cloud teams. In that regard they are doing pretty well. Plus all the folks that never paid for ExcelsiorJET, JRockit, PTC, Aicas, and many others of which only PTC and Aicas survive, now have in Graal their gratis AOT compiler. Alongside OpenJ9 (whi…

In my experience JRuby is way more viable than Jython ever was, one because Ruby native modules were more often thin wrappers, two because Ruby has sorta-standard in form of test suite (which AFAIK evolved from one that was necessary for ISO Ruby effort), and established somewhat case of using different implementations..

And C extensions never got as crazy as in python, and some major ones either made Java backends or switched from MRI embedding to FFI

Re: Saying goodbye to asm.js

#158

Post by p_l »

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 way I remember it, NaCl and PNaCl ended up nowhere not because big, but because Mozilla, then with big influence on standards, declared them not web enough for the crime of not being JavaScript and pushed against any addition of it into Gecko in any form and promoted "JavaScript is all you need" including an early demo of decoding video in JS - which I recall disgusted me because I somehow knew it would take away various technical issues preventing proprietary encoding from closing down web videos.

Funnily enough, NaCl had its origins in Mozilla extension, with old versions IIRC mentioning lineage starting in Google Gears extension for Firefox

Re: Saying goodbye to asm.js

#159

Post by burntcaramel »

spartanatreyu wrote: post #132
burntcaramel wrote: post #128

Earlier quoted context omitted.

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…

The sudoku example has something massively wrong with it's performance. Latency is over a second per click and it halts after a few clicks. The QR example works fine though

Thanks, I had shipped a bug in the event system. The performance should be much improved now.

Re: Saying goodbye to asm.js

#160

Post by burntcaramel »

dmazzoni wrote: post #131
burntcaramel wrote: post #128

Earlier quoted context omitted.

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…

Do you really think this "works great"? I'm using a brand-new MacBook Pro with a high-end M5 processor, and this site is extremely unresponsive for me. Huge latency between clicking and getting feedback. It also breaks accessibility. The QR code use case seems far more reasonable to me, you're generating a static image.

It definitely wasn’t “working great”, I’ve now fixed a bug in the event system that was causing loops. The performance should be improved now.

Yes, accessibility is a key concern of mine, I’m keen to explore html-in-canvas as a way to have an accessibility tree combined with a rendered interaction.

I’m personally at a stage where React and CSS have pushed to DOM to extremes of complexity and difficultly in optimization that I desire simpler ARIA-based HTML combined with custom rendering. I’m hopeful that it will be easier to test, lighter for users, and faster for everyone.

Post reply on HN