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.
PNaCL doesn't exist yet, so there is nothing to push.
Dart is a much more interesting question.
That said, is there really value in having two and only two languages available (and leaks when you try to use both together in nontrivial ways) compared to using JavaScript as a compilation target? I guess it depends on how good a fit Dart is for your use cases...
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.
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.
> 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.
"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?
> 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.
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.
> 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.
Question for skatepark: If PNaCl were finished now and supported by every major browser, what would you do with it? Would you use it to supplement the existing web stack for performance-critical code? Or would you write whole applications in some other language (if so, which one?) and target the browser via PNaCl?
We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms.
With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X.
My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.
> My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.
You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. What tools do you need to provide a good user experience that the web as it is now doesn't have?
- The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.
- Performance.
- Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing.
- Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform.
- Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation.
- Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.
- Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.
I will now relent of defending Mozilla, in which I have zero vested interest. Mozilla's mission and approach seem good on paper (or in HTML), but you make good points.
It seems to me, on reflection, that I have been playing the role of religious apologist, while you have been the skeptic. This is ironic, because I have been in the opposite sitaution with regard to my former real religion for the past couple of years.
It seems to me that Android is the closest thing we have to a non-proprietary application platform, and even that is more tightly controlled by one company than we might like.
For now, I guess the best approach to writing great apps is to write the UI-independent core in a reasonable cross-platform language, and then use each platform's native UI constructs. iOS makes this difficult for any language higher-level than Objective-C, since there can be no JIT compilation for iOS. But I'm thinking now that C# might be a reasonable cross-platform language, given Xamarin's work on Mono for mobile platforms.
> Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
How does separating UI styling from UI construction code make creating reusable components more tricky exactly ? Other points might be close-ish to the mark but this one seems way off.
To address a couple of things that you said more directly:
> Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps?
Yes, I have been serious, and sincere, throughout this dialogue. I guess I really am that out of touch with how truly excellent desktop and mobile apps are developed. I have done most of my work in dynamically typed languages (Python, Lua, and JavaScript), with little regard for performance. When developing any UI more complex than a yes/no dialog on Windows, I have generally reached for HTML (embedded MSHTML to be specific), despite its shortcomings. On Mac and iOS, I have been lucky in that I can use Lua while still having a native UI and platform integration.
It seems to me that while mainstream desktop and mobile platforms have been mediocre in their various ways, none has forced mediocrity upon the application developer as much as the Web platform.
> - The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety.
When I was defending Mozilla and the Web platform, my response (in true quasi-religious fashion) would have been to keep having faith in the almighty tracing JIT compiler. But I was reading yesterday about tracing JIT compilers, and I noticed that they need guards around loads and stores in case the inputs to a particular invocation of a trace are of different types than the types for which the trace was compiled. You're right to point out that compile-time type safety has some performance benefit. For truly performance-critical code, asm.js does provide for static type checking and AOT compilation. Still, we have yet to see how many browser makers will implement these things.
> - Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing.
Yes! Yes! I most emphatically agree with this point. It seems to me that modern web application UIs are still a free-for-all, with many app and toolkit developers defining their own widgets as they see fit. In contrast to the Apple platforms, GNOME, and even Windows IIRC, there's no set of human interface guidelines for the Web platform.
> - Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't.
Mozilla is introducing new APIs to expose more platform features, at least for Firefox OS and Firefox for Android. But that does little good for today's mobile application developers. And I guess it's a distinctive behavior of any "true believer" to have faith that promises will be fulfilled at some indeterminate future time, and encourage others to do the same.
> - Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult.
I'm not quite convinced on this one. Reusable component toolkits do exist for the Web platform, so presumably most application developers don't have to do this very difficult work. Can you elaborate some more on what's wrong with the HTML/CSS/JS trio, or point me at an existing critique that you think is on target?
I think I have identified a few potentially faulty assumptions underlying your comments.
You assume that the only reason that Mozilla is the only major player to push JavaScript as the way forward is that Brendan invented JS. Another interpretation which is less cynical toward Mozilla is that the other players are most interested in their own platforms, whereas Mozilla is most interested in the Web as a whole. A JavaScript runtime is the one runtime that all browsers have, so rather than fragment the landscape with a second runtime, Mozilla is pushing JS as the way forward.
You assume, as if it were an axiom, that compiling other language to JavaScript is less efficient than compiling to LLVM bitcode and/or x86/ARM native code. I'll take these separately.
Targeting JavaScript versus LLVM bitcode: For good performance, either of these will be JIT-compiled to native code. 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.
Targeting JavaScript versus native code: Last I checked, Google is not going to push NaCl for standard web apps until PNaCl is ready. So we'll need the cross-platform target and JIT compilation anyway. You may argue that even when PNaCl is ready, application developers will also ship x86 and/or ARM builds for maximal efficiency. But let's dig a little deeper: in all likelihood, the PNaCl, x86, and ARM builds are all generated by a compiler from a single intermediate representation. In principle, why couldn't a subset of JavaScript be compiled to equally efficient native code? Even assuming that offline ahead-of-time compilation yields more efficient code than JIT compilation, a browser could observe which apps the user uses most, and apply more aggressive offline compilation to those apps. So it is by no means imperative that application developers ship native code.
You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper, is unequivocally holding back the Web as an application platform. Let's drill down into specifics. What features do NaCl and Pepper provide that aren't (yet) covered by standardized APIs? My understanding was that Canvas and WebGL are helping a lot.
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. For good performance, you'd need something to compile your source language to something else anyway, either JS or LLVM bitcode. Might as well be JS.
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. Indeed, none of the other major players you've mentioned, not even Google, is as serious about the Web -- the open Web -- as Mozilla.
> 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.
> As simple aggregate counter-evidence, I will point to the popularity, performance, consumer, and developer adoption of mobile platforms.
This only implies that native mobile applications are more popular than mobile Web applications; it doesn't imply any particular reason why. At best, NaCl was still in the research phase when native mobile apps started to catch on, so Mozilla's refusal to get behind NaCl is irrelevant to the popularity of native mobile apps.
> 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.
Are you arguing that for optimal performance, applications will always need to be distributed as native machine code? I will be disappointed if it turns out that they do, because that's how we get locked into proprietary platforms, at the CPU level if not at the OS level.
> You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here.
Yes, I was aware. Perhaps I overstated the importance of JIT compilation. However, I think we need more data. Some comparative benchmarks between RubyMotion (in the simulator) and a JIT-compiled Ruby (on the same Mac) would be relevant.
(Or did I, from my Throne of Skulls, send my T-1000 back in time to stop NaCl from being used by Apple on the first iPhone? Mwa-hah-hah!)
On Skatepark's planet it seems (a) Android (definitely a mobile platform, now the biggest one by users) has native-speed Dalvik apps; and (b) most developers write those in preference to hybrid or web-only apps.
Not so on Earth. Regarding (a), SpiderMonkey (and I'm pretty sure V8) beat Dalvik on same hardware on standard benchmarks. On (b), when last I checked over 70% of Google Play apps used embedded WebViews.
Only by reading "mobile" as "iOS" do the commenter from another planet's performance assertions even half-way hold up. The historical cause/effect claims just don't make sense (unless I do have backward time travel).
"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."
The JVM is a much higher-level bytecode than asm.js; asm.js is essentially just a JS encoding of LLVM. To name just one example, the JVM's memory model is composed of garbage-collected objects, while asm.js' memory model is a heap and stack as a linear array of bytes. There's a world of difference between the JVM intermediate language and the LLVM/asm.js intermediate language.
The idea that the LLVM intermediate language cannot be compiled into something as efficient as native code is trivially disproven by the fact that this is how clang works: it compiles to LLVM IR and then to native code.
"You are aware that Mono AOT compiles C#, correct? As does RubyMotion. JIT is not strictly necessary here."
Polymorphic inline caching, essential for performance of dynamic languages, requires self-modifying code.
> asm.js is essentially just a JS encoding of LLVM
This seems like a bit of a stretch; how do you encode an indirect branch in JS?
But it looks like an interesting project and I look forward to seeing what they are able to accomplish. I think it may be difficult to get native code performance while also being a secure enough sandbox to run in-process with the browser. LLVM is fast in large part because does not have the requirement of being a sandboxed attack surface. Making it safe will require performance compromises, like guards on loads and stores. Even (P)NaCl, despite its sandboxing, runs in a separate process, limiting the damage if the sandbox is broken out of. JavaScript has traditionally taken the approach of achieving safety by exposing only high-level concepts (objects, attributes, etc); if it aims to support lower-level programming idioms with low overhead that may be at odds with also being highly safe.
It's an interesting design space and I will be curious to watch the project evolve.
"This seems like a bit of a stretch; how do you encode an indirect branch in JS?"
asm.js has a switch instruction to cover most uses of indirect branches. First-class function pointers are being worked on for a future version of the spec. So this should cover the vast majority of use cases of indirect branching. If this is not enough, I could imagine an extension of JavaScript to support e.g. first-class labels. (Note that LLVM did not support first-class labels for a long time, and of course portable C does not.)
"Making it safe will require performance compromises, like guards on loads and stores."
Naturally, but this is also the case with NaCl or PNaCl, unless NaCl drops all of its software fault isolation techniques and starts relying solely on the OS sandbox. I suppose in theory one could compile asm.js in this way if it was really desired. The entry and exit points from asm.js to the DOM are fairly well defined, so in theory one could IPC them as well.
I'm personally skeptical that asm.js adds much more security risk over the JavaScript JIT that already must exist, however; the semantics of asm.js are extremely simple even compared to LLVM (as asm.js is untyped), much less the full semantics of JavaScript.
> 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, that goal was achieved ;-)
> You are aware that Mono AOT compiles C#, correct?
Java can be compiled straight to native code too. GCJ works like that for instance. The resulting performance from binaries of such compilers is abysmal though.
C# is not really a good example because C# was designed for AOT compilation. For example, most methods in the standard library are not polymorphic and methods in C# are final by default, whereas with Java it's the complete opposite, with methods being virtual by default. With all respect to Mono and Xamarin, it's hardly an epitome of performance.
Also, right now JRuby trumps in performance just about every other Ruby implementation available, including MRI, RubyMotion, Rubinius or IronRuby.
> JIT is not strictly necessary here
For dynamic languages, if you want decent performance, all the known techniques require JIT techniques. One of the most important optimizations the JVM does is inlining of virtual method calls at runtime, something which is impossible to do ahead of time. Another important technique is tracing JIT compilation, used successfully in recent Javascript engines (except V8 I think) and by Lua [1]
All known techniques for optimizing dynamic languages or runtime-polymorphic method dispatch require recompilation of code based on changing conditions.
This ... has not been my experience. And I write a lot of high-performance native and Java code.
> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.
Then adopt a bytecode standard so that it can be JIT'd. I don't believe that NaCL is the end of the conversation, just that Mozilla has consistently prevented the conversation from starting, and refused to participate in it unless it involves Eich's JavaScript as the baseline implementation language.
So, you want a standard program representation that's amenable to JIT compilation. But why, exactly, does it need to be a bytecode format, rather than source code in a standardized language?
Let me reiterate some of the advantages of JavaScript:
* A performance arms race among JavaScript implementers has been underway for nearly half a decade now. JS thus has a head start in that area over any hypothetical language or bytecode format that might be integrated in a browser.
* JS already has first-class access to the DOM -- the API that all the browsers already have -- as well as all the other up-and-coming APIs.
* There are already JS debuggers, and with source maps, these debuggers can even be made to work with other languages that can be compiled to JS. All JS developers benefit from this, as well as all developers who use languages that compile to JS.
So basically, JS has a head start over NaCl, Dart, or any other potential "clean" replacement.
As far as I can tell, your only objection then is that there's something aesthetically wrong with using a quirky high-level language as a compilation target for other languages. To that I can only say that worse is better. We might as well get on with the business of writing great apps with the tools we have.
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.