Hacker News Reader

Comment by lucian1900 | Hacker News Reader

lucian1900

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.

View on HN

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.

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

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.

I don't really see this as a fundamental, iron clad barrier to everything you mention above.

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?

Search for "LLVM IR is a compiler IR".

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.

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.

> asm.js is just running in the JS VM

And it has a nice spec! :)

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.

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

Emscripten is trying to move their backend into LLVM which would accomplish the same thing.

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

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!"

Reply on news.ycombinator.com