Is there really anyone other than Eich -- producing ANY platform -- that thinks that JavaScript is the correct baseline virtual machine to target?

Breakdown of low-level targets:

Google: Native, NaCL, PNaCL, Dalvik

Apple: Native, LLVM (eg, for OpenGL feature emulation).

MS: Native, CLR

Oracle: JVM, Native

Mozilla: JavaScript

Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?

Eich is the CTO and sets the technical direction for one of the four major browsers. The browsers can only move forward standards in cooperative with one another.

This isn't a fantasy world.

> Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?

Then maybe they could propose a solution to the problem other than adding more JavaScript? Mozilla also dislikes standardized bytecode and virtual machines:

http://www.aminutewithbrendan.com/pages/20101122

To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers, and going with the latter sounds eminently reasonable to me. The x86 bytecode encoding is really ugly too (look at those one-byte-long binary coded decimal instructions), but the survival characteristics of backwards compatibility are undisputed...

A better technical solution and lower development friction throughout the entire stack. The hackiness of the web already introduces an enormous amount of cumulative friction, and asm.js just adds more.

People have been asking for a solution -- and working on them -- for 5+ years, and Eich has consistently replied that such a thing is unnecessary. In many respects asm.js is an admission of defeat, in that it's not standard JavaScript (it's a strictly designed subset), and they are attempting to tune it to the purpose of providing a standard bytecode format, while still being able to claim that it is JavaScript.

In the same period of time, entirely new and proprietary mobile platforms have emerged and eaten a huge portion of the application market's mindshare and marketshare.

Perhaps it's time to stop listening to someone who can't think outside his own box, and instead choose a technology that is actually well-suited to the problemspace.

> To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers ...

That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform.

Human readable JavaScript "byte code"? Seriously? This is the kind of backwards thinking that left the door wide open for native mobile apps to own the market.

I would love to be able to target the web instead of proprietary platforms, but the technology stack isn't there and won't be as long as people like Eich are running the show, and remain fixated on what worked for web documents as the solution for what will work the future of web apps.

Going with a worse-is-better solution for the purposes of backwards compatibility is always an admission of defeat. But it's a very practical one. It's an admission of defeat that has made Intel and Microsoft billions, for example.

"while still being able to claim that it is JavaScript."

But it is JavaScript. The ECMA-262 spec says how to interpret it.

"That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform."

And then Web developers have to ship two binaries. Foisting the problem of backwards compatibility onto Web developers for the sake of making a nicer bytecode parser doesn't seem like a win to me.

Do you think a systems/application developer, who believes in those ideas, would choose to work at, or be a part of, Mozilla, given Eich's clear and verbose positions that stand entirely apart from decades of success shipping consumer applications for desktop and now mobile devices?

As someone who writes consumer applications, I want a common application platform, but I'm not going to sacrifice my tooling, work quality, or user experience to contribute to a fundamentally flawed approach, just because it's "open".

NaCl and Dart were both created in a Dart room without anyone else's input.

Google at least understands the flaws. Web developers seem to have their head in the sand while mobile may very well eat their lunch.

Mozilla is not a dictatorship - it's a nonprofit open source project. Obviously Brenden is a pivotal figure but people have many opinions on many topics, just read the mozilla mailings lists (which are public).

On this topic, AFAICT the great majority agree with Brendan.

I'm just not interested in continuing to try fit the square peg of DOM/CSS/JS into the round hole being an application platform. It has been made clear from Brendan (for at least half a decade now, if memory serves) that this is what they're doing and will continue to do.

In the meantime, iOS and Android appeared from nowhere and turned the engineering departments of many companies -- most of which were previously focused solely on server+web -- on their head.

At the same time, Google can barely give Chrome Books away. This must tell you something about the efficacy of these strategies.

NaCl actually offers crappier APIs than the Web platform, and it runs in a box where it can't directly manipulate the real Web APIs. asm.js is intriguing because it offers a very natural path to a foreign function interface to all the stuff exposed to JS.

They also provide great battery life and user-visible performance (iOS especially), have incredibly well integrated development tools (see Apple's Instruments and its power, CPU, syscall, et al profiling), and give software authors the escape hatches they need to maximize performance when absolutely necessary.

It's not just a question of nice APIs. Layering another level of JavaScript spit and bubblegum on top of the problem is t going to make any of the above easier.