6 ms·

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

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.

skatepark 14y ago
> 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.
- pcwalton 14y ago
  "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.

skatepark 14y ago

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

pcwalton 14y ago
"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.