Hacker News Reader

Comment by asb | Hacker News Reader

"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows them to 1) make use of their existing JIT compiler and 2) avoid defining a new bytecode format (the benefits of this are questionable). asm.js is ugly, but it doesn't seem that much more ugly than adding a new multi-megabyte dependency to every browser.

I suppose an interesting question would be how hard would it have been to standardise on the PNaCl bytecode format and use that as the input to ${FOO}monkey

View on HN

Or they value backwards compatibility. Any asm.js you output will run with the same semantics and most likely pretty good performance whether or not the browser supports asm.js. Feed PNaCl bitcode to anything but special builds of Chrome and you may as well be streaming from /dev/random.

> "Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM.

Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage."

In other words, Flash reincarnated.

Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage." In other words, Flash reincarnated.

Who cares? Asm.js apps are little black boxes.

From a technical perspective, using JS as a bytecode is less than optimal, of course.

But asm.js is a good backdoor. Good luck getting some third party bytecode added to MS's and Apple's browsers. There was a fairly popular bytecode used in web apps: Java.

> There was a fairly popular bytecode used in web apps: Java.

At least two, actually: Flash is another. Arguably better performing and more generally successful. And both of them were mostly open... freely targetable as runtimes, and almost freely re-implementable.

With as much hate as both of them have had, I find it a little weird when someone talks about doing it again, but then again, maybe the people who hated Flash aren't the same people who want a Google VM.

Or maybe they think third time's the charm.

I don't think you really need to import LLVM to use bytecode, nor do I think that bytecode must look anywhere like say LLVM bitcode.

I specifically listed freedom of choice as a bytecode benefit for implementors.

You can have bytecode and pipe it through a separate front-end into your JavaScript JIT compilation pipeline.

You can have a separate compilation pipeline as well, if you think it is better.

I didn't mean to imply you had said that. Sorry if my wording gave that impression.

oh, no. I was not saying that I have such an impression. I sometimes wrongly use "I did not say" as "I don't think" as a habit, literal translation from Russian where it does not have critical connotation.

I fixed the comment above.

Wouldn't they want to eventually use LLVM to compile Asm.js anyway?

Surely LLVM will produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it.

OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to forever support a specific LLVM bitcode version.

I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...

I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.

I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.

I think the main reason for anyone not to support it, would be that it makes the WWW platform specific.

I can't wait for my first "Sorry. This webpage does not support ARMv7 Hard-float".

Another reason Mozilla might not support this is that it's actually not called Na(tive) Cl(ient). It's full name is "Google Native Client".

That sure as hell doesn't sound like a standardized and fully spec'd thing I'd implement in my browser if my name was anything besides Google.

Reply on news.ycombinator.com