> For Google to push anything forward (NaCL, PNaCL, dart), they need at least one other major browser vendor to join them. Apple and Microsoft have vertically integrated native application markets, and have no reason to further the development of the web. That leaves Mozilla.
Yes, but Mozilla still needs to be convinced that the new technology makes sense for the web. Mozilla collaborates with Google on lots of new things for the web (WebRTC, see recentl HN stories on interoperability between Chrome and Firefox there, Web Intents, etc. etc.), but it does disagree on NaCl for example.
> An alternate explanation that doesn't involve a fantasy world where Brendan Eich issues oppressive decrees from his throne of skulls ...
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:
What would a standardized bytecode bring to the table over asm.js?
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...
> What would a standardized bytecode bring to the table over asm.js?
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.
"In many respects asm.js is an admission of defeat"
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 note that Mozilla is not a hive-mind, and people disagree with Brendan on a regular basis. I haven't heard of anyone within Mozilla who was actually interested in NaCL/PNaCL/dart.
As a said to another commenter, this is selective bias.
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".
You're a web developer, yes? In my circles NaCL is looked at with interest because there's no way possibly for us to produce apps to the level of quality we do elsewhere -- and without a huge amount of pain -- while using the web's organically grown technology stack.
Google at least understands the flaws. Web developers seem to have their head in the sand while mobile may very well eat their lunch.
> Yes, but: Mozilla disagrees because Eich disagrees
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.
It's selective bias. I, like many other professional application and systems engineers who didn't originate in the web space, wouldn't participate in Mozilla, nor try to work there.
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.
iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications.
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.
> iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications.
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.
Yes, but Mozilla still needs to be convinced that the new technology makes sense for the web. Mozilla collaborates with Google on lots of new things for the web (WebRTC, see recentl HN stories on interoperability between Chrome and Firefox there, Web Intents, etc. etc.), but it does disagree on NaCl for example.