skatepark

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

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.

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.

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.

> I think I have demonstrated that Mozilla's insistence on JS and other standards is not holding back the Web as an application platform by any means.

I don't really believe that you have. As simple aggregate counter-evidence, I will point to the popularity, performance, consumer, and developer adoption of mobile platforms.

More specifically:

> To claim that LLVM bitcode is a better target, you need to show that some JIT compilation technique implemented by LLVM/PNaCl is made impossible by JavaScript the language. JS typed arrays provide a C-friendly memory model; I don't know of anything else that's missing. I'd be happy to be educated though.

In the earlier days of Java, a common refrain was that the JVM could get better-than-native performance because it could make runtime decisions about JIT optimization. In reality, the complexity of performing this task generally outweighs the benefits compared to native code, and the JVM hasn't really succeeded outside of specific micro-optimizations. As a whole, the JVM is still slower than most native code.

Your argument seems to be predicated on a similar fallacy. The notion that since you can, in _theory_, optimize JS down to an efficient byte-code (or even AOT compile it), it is as good as an efficient and well-defined byte-code to begin with.

Yet, we have numerous historical examples of how adding more complexity between you and your intended target (eg, performance, versatility) doesn't help you achieve it. JS is an expensive and complicated intermediate.

This is equivalent to selling something at a loss and claiming you'll make it up in volume. You're adding complexity and challenge to an already challenging problem.

> You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper ...

Actually, NaCL and Pepper have nothing to do with the DOM argument. The DOM argument is just an example of where rigorious adherence to what worked for documents is not working for applications.

> Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again.

You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here.

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.

It's the users that pay the cost, instead of the developers. Mobile is winning the app war for a reason.

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

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

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

Yes, but: Mozilla disagrees because Eich disagrees, and Eich disagrees because he's built his entire career on top of his invention of JavaScript.

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

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

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

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

PNaCL -- and any other alternatives -- are in no small part incomplete because Eich has stated repeatedly in no uncertain terms that its JavaScript or nothing.

If you want to produce an alternative, there's no chance of it being accepted.

Imagine this sort of total language myopia in any other general purpose platform.

Mozilla -- and Brendan Eich specifically -- have held back the web as a platform for years.

Brendan Eich is myopically focused on the DOM and JavaScript monoculture -- rather than the underlying potential of the web: a standardized and completely open application platform.

I assume this is due to his own vested interests and personal investment as the author of JavaScript, but it has been incredibly damaging to the web as a whole. 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.

If Mozilla genuinely cares about providing an open application platform (ala Firefox OS), they'll put Brendan Eich out to pasture and focus on moving past his stranglehold on JavaScript+HTML.