5 ms·

I'd really much prefer something lower level, so anything can be easily implemented on top with predictable performance (including JavaScript). I don't underst

by lucian1900 14y ago

I'd really much prefer something lower level, so anything can be easily implemented on top with predictable performance (including JavaScript). I don't understand the resistance to PNaCl, it's plugins done right.

tachyonbeam 14y ago
They really want the performance of asm.js code to be predictable, and as a compiler writer, I believe this is entirely possible. The subset of JS they use is made to have good performance. The people here don't seem to like some of the implementation details of NaCl. I think they also might just not want to let Google impose something. Also, the inventor of JavaScript is the Mozilla CTO (shhh!). I'm partial to PNaCl too. I think it's probably better, in the long term, to have a standard bytecode format to compile to... But, asm.js might win this war, just because the road to asm.js support is much shorter. You basically already can compile C programs to asm.js and have them run cross-browser. Worse is better?
- JA1001AC 14y ago
  Search for "LLVM IR is a compiler IR".
dherman 14y ago
There are good and bad things about PNaCl. But overall, the resistance to PNaCl goes beyond Mozilla -- it's a really hard standardization/synchronization problem. Our goal with asm.js was to produce something that could work today (because it's 100% compatible with existing JS semantics) and work even better tomorrow as engines optimize it even better. Edit: Re: predictable performance, that's exactly what asm.js is about. The performance model is much closer to that of C or PNaCl/LLVM.
azakai 14y ago
This is lower-level. It is JavaScript, but really it is a subset that implements low-level operations. In fact lower than PNaCl, this is past the LLVM IR level.
- dochtman 14y ago
  So will there be code to turn LLVM IR into asm.js stuff? That would be pretty awesome (and a nice way to make Emscripten more accessible to other languages?).
  - jevinskie 14y ago
    Emscripten is trying to move their backend into LLVM which would accomplish the same thing.
  - azakai 14y ago
    > So will there be code to turn LLVM IR into asm.js stuff? There already is, that is precisely what emscripten does when run with the ASM_JS=1 flag set. Emscripten's input is LLVM IR, not C or C++. (Although, it has been mostly tested on LLVM IR generated from clang that was given C or C++.)
- nnethercote 14y ago
  I bet if you rewrote the spec to use a different syntax, and didn't mention that it (syntax aside) is a subset of JS, people would be falling over themselves to say "finally, proper bytecode for the web!"
comex 14y ago
It's plugins done right with the gigantic caveats that it duplicates a large swath of low-level DOM APIs, requiring a large amount of effort to write two implementations of essentially the same things, and has no direct access to the DOM or external JavaScript, meaning it lacks support for some APIs (WebRTC) and cannot really be used as a drop-in replacement for JS or to take advantage of the existing HTML renderer (it's all or nothing). That is, it's plugins done right if you insist on living in a separate process, despite the adequacy of both NaCl and JS engines' ability to keep code within the inner sandbox/VM, and what should be the adequacy of the sandbox of renderer processes even if someone manages to run native code in it. Me, I'd prefer to just run emscripten on the Python interpreter, take advantage of a very small VM that nevertheless is apparently able to run code at half native speed, and start using a new language on top of all the nice existing stuff.
- stcredzero 14y ago
  > has no direct access to the DOM or external JavaScript, meaning it lacks support for some APIs (WebRTC) and cannot really be used as a drop-in replacement for JS or to take advantage of the existing HTML renderer (it's all or nothing). Is there some fundamental reason why these won't all get solved in the future?
  - comex 14y ago
    The fundamental reason is that Pepper plugins live in a separate process, so latency is high - a security measure, but one that I'm arguing is unnecessary and forces highly unfortunate design choices.
    - stcredzero 14y ago
      I don't really see this as a fundamental, iron clad barrier to everything you mention above.
bzbarsky 14y ago
The resistance to PNaCl is twofold: 1) It's nonexistent so far, as far as I can tell, after years of research+work (unlike asm.js, which took one engineer a few months to implement a compiler for in Mozilla). Or can you actually use PNaCl in Chrome now? Or is there a concrete timeframe for when it'll be ready? 2) PNaCl involves pulling in all of Pepper, which is undocumented and very much tied to Chrome's architecture last I checked. Other browsers don't want to get on the "chase Chrome's Pepper implementation" treadmill. asm.js is just running in the JS VM, so talks to the DOM (and GL and networking, etc) in the normal way, which browsers already implement.
- nnethercote 14y ago
  > asm.js is just running in the JS VM And it has a nice spec! :)

tachyonbeam 14y ago

They really want the performance of asm.js code to be predictable, and as a compiler writer, I believe this is entirely possible. The subset of JS they use is made to have good performance. The people here don't seem to like some of the implementation details of NaCl. I think they also might just not want to let Google impose something. Also, the inventor of JavaScript is the Mozilla CTO (shhh!). I'm partial to PNaCl too. I think it's probably better, in the long term, to have a standard bytecode format to compile to... But, asm.js might win this war, just because the road to asm.js support is much shorter. You basically already can compile C programs to asm.js and have them run cross-browser. Worse is better?

JA1001AC 14y ago
Search for "LLVM IR is a compiler IR".

dherman 14y ago

There are good and bad things about PNaCl. But overall, the resistance to PNaCl goes beyond Mozilla -- it's a really hard standardization/synchronization problem. Our goal with asm.js was to produce something that could work today (because it's 100% compatible with existing JS semantics) and work even better tomorrow as engines optimize it even better. Edit: Re: predictable performance, that's exactly what asm.js is about. The performance model is much closer to that of C or PNaCl/LLVM.

azakai 14y ago

This is lower-level. It is JavaScript, but really it is a subset that implements low-level operations. In fact lower than PNaCl, this is past the LLVM IR level.

dochtman 14y ago
So will there be code to turn LLVM IR into asm.js stuff? That would be pretty awesome (and a nice way to make Emscripten more accessible to other languages?).
- jevinskie 14y ago
  Emscripten is trying to move their backend into LLVM which would accomplish the same thing.
- azakai 14y ago
  > So will there be code to turn LLVM IR into asm.js stuff? There already is, that is precisely what emscripten does when run with the ASM_JS=1 flag set. Emscripten's input is LLVM IR, not C or C++. (Although, it has been mostly tested on LLVM IR generated from clang that was given C or C++.)
nnethercote 14y ago
I bet if you rewrote the spec to use a different syntax, and didn't mention that it (syntax aside) is a subset of JS, people would be falling over themselves to say "finally, proper bytecode for the web!"

comex 14y ago

It's plugins done right with the gigantic caveats that it duplicates a large swath of low-level DOM APIs, requiring a large amount of effort to write two implementations of essentially the same things, and has no direct access to the DOM or external JavaScript, meaning it lacks support for some APIs (WebRTC) and cannot really be used as a drop-in replacement for JS or to take advantage of the existing HTML renderer (it's all or nothing). That is, it's plugins done right if you insist on living in a separate process, despite the adequacy of both NaCl and JS engines' ability to keep code within the inner sandbox/VM, and what should be the adequacy of the sandbox of renderer processes even if someone manages to run native code in it. Me, I'd prefer to just run emscripten on the Python interpreter, take advantage of a very small VM that nevertheless is apparently able to run code at half native speed, and start using a new language on top of all the nice existing stuff.

stcredzero 14y ago
> has no direct access to the DOM or external JavaScript, meaning it lacks support for some APIs (WebRTC) and cannot really be used as a drop-in replacement for JS or to take advantage of the existing HTML renderer (it's all or nothing). Is there some fundamental reason why these won't all get solved in the future?
- comex 14y ago
  The fundamental reason is that Pepper plugins live in a separate process, so latency is high - a security measure, but one that I'm arguing is unnecessary and forces highly unfortunate design choices.
  - stcredzero 14y ago
    I don't really see this as a fundamental, iron clad barrier to everything you mention above.

bzbarsky 14y ago

The resistance to PNaCl is twofold: 1) It's nonexistent so far, as far as I can tell, after years of research+work (unlike asm.js, which took one engineer a few months to implement a compiler for in Mozilla). Or can you actually use PNaCl in Chrome now? Or is there a concrete timeframe for when it'll be ready? 2) PNaCl involves pulling in all of Pepper, which is undocumented and very much tied to Chrome's architecture last I checked. Other browsers don't want to get on the "chase Chrome's Pepper implementation" treadmill. asm.js is just running in the JS VM, so talks to the DOM (and GL and networking, etc) in the normal way, which browsers already implement.

nnethercote 14y ago
> asm.js is just running in the JS VM And it has a nice spec! :)