Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl.

Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/. Cross-browser.

/be

> Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl.

No, you've simply held back the only other entity interested in making the web a viable app platform:

- MS and Apple, and Google's behavior are aligned with their corporate incentives.

- In theory, Mozilla's behavior ought to be aligned with the interests of the web at large, but in practice, Mozilla is aligned with you, and your behavior is aligned with your own personal interest in a web platform monoculture based on your technology.

Mozilla and Google, in concert, have the ability to make it a market necessity for Apple and Microsoft to follow suit. Google alone does not.

This makes you the lynchpin at an organization that in theory was created for the very purpose of advancing the interests of the web.

> Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/. Cross-browser

It takes a True Believer to abandon decades of research, ignore repeated market successes (in the application platform space) that vastly surpass anything they've produced, and then continue to myopically push their own invention into areas where it simply does not belong.

The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset, on top of which implementors will have to invest even more time and complex effort in providing quality implementations.

This is death by a thousand cuts.

"on top of which implementors will have to invest even more time and complex effort in providing quality implementations."

It is actually quite easy to implement asm.js; you just carve a "native mode" out of the VM infrastructure that already exists. Much easier than inventing a full-stack VM from scratch.

It'd be even easier with a clean bytecode, and it wouldn't require nearly as much effort and round-about solutions. It also would simplify portable tool development, including source-level debuggers.

And if we're living in a fantasy world, we can all get a pony, too. The fact remains that JavaScript is widely deployed and has multiple viable competing implementations. Any hypothetical bytecode format starts at a huge disadvantage due to this reality. The path of least resistance here is to target JavaScript.

The "path of least resistance" has not been particularly successful in helping the web provide a robust platform for application development over the past 10 years. I don't see why the hack-and-slash "pragmatism" should be expected to start working now.

Now you are just smoking crack. The web is hands-down the most widely used application platform in the world, and you're going to claim it's not a robust platform for application development? I don't know what planet you live on.

The web is the most widely used document platform in the world.

And no, it's not a robust application development platform. Working with it is an exercise in constant compromise between bad technologies and the quality of the user experience.

You're smoking something too, if you're equating the content-centric web with the breadth and depth of the market of native mobile and desktop apps.

Of course, I also get a better experience from the NYTimes mobile app; it's simply that the web can do content less badly than it can do apps.

I shudder in horror at writing one of our large apps in JavaScript, maintaining it, and desperately trying to keep frame rates up (yes, that does matter to more than just games), conform to some sane semblance of platform standards to which users are accustomed, reuse a platform widget toolkit, etc.

The myopia of the web crowd is why your platform continues to suck.

> The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset

I'm surprised you find that approach controversial. Have you not seen the awesomesauce that Re2 and PyPy bring to the table by defining strict subsets of PCRE and Python, respectively?

> JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack.

Honestly that's only an implementation dependent detail. If there is a fast compiled Lisp like SBCL, a fast JavaScript can certainly be done.

> Honestly that's only an implementation dependent detail.

Not really, no. JavaScript is a ridiculously high-level target for another language, and this introduces a huge amount of complexity in any effort to target it efficiently.

You can pare down JavaScript, as Eich seems to be banking on, but what possible technical reason is there for this? If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode, and let those browsers be slow and complicated and have worse development tooling.

"If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode"

Which is precisely what the Mozilla Emscripten project does.

Emscripten doesn't treat LLVM bitcode as a first-class target, it treats it as an intermediate target to be translated into JavaScript.

[high level language] -> [low level representation] -> [high level language] -> [low level representation] -> [execution]

This is ridiculous to aim for as your first-order target.

PNaCL is "incomplete" (as in, not working) because no one actually knows how to make it work, though they've been trying to figure it out for years. The fact that it's a hard problem has nothing to do with Brendan saying he doesn't like the idea.