4 ms·

Not direct technical reasons, no. The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty

by pbsdp 13y ago

Not direct technical reasons, no. The only indirect technical justification is in maintaining compatibility with existing browsers, but that falls over pretty fast when you're a browser maker (Mozilla) and refusing to work with another browser maker (Google) on jumping over that compatibility hurdle.

mistercow 13y ago
Can you explain specifically what you mean by a "direct" vs. an "indirect" technical reason?
- pbsdp 13y ago
  Direct: Constraints/requirements directly related to implementing a maximally effecient runtime architecture. Indirect: Market constraints that drive technical limitations. When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning. Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.
  - azakai 13y ago
    > compared to the current state of the art What do you consider the current state of the art?
    - pbsdp 13y ago
      JVM, CLR, Mono AOT complation, NaCL/PNaCL. A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d). Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.
      - azakai 13y ago
        Those examples are all very different. What is your goal - speed? Code size? Portability? Security? Those examples don't all achieve those to the same degree, and I would argue that modern JS VMs are competitive with them in many respects.
        pbsdp 13y ago
        > What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the state of the art. > ... and I would argue that modern JS VMs are competitive with them in many respects But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg. Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing. Let language authors target the low-level machine, and target your high-level general purpose bytecode. Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.
        azakai 13y ago
        JS VMs make tradeoffs, yes. Regarding your specific examples: 1. Shared-state multithreading. This has been proposed by various people in the past, and is still being debated. There are people for it and against it in various places. It might happen, if there is consensus to standardize it. 2. SIMD: PNaCl (which I mention since you mention NaCl in that context) does not have SIMD. But of course it can add SIMD, just like Mono and Dart have, and there is a proposal for JS as well, hopefully that will get standardized. So even those limitations are in principle resolvable. They do depend on standardization, of course, but so would any VM you want to run on the web. > Let language authors target the low-level machine, and target your high-level general purpose bytecode. asm.js is meant to get performance similar to a low-level machine. It's already very close to native on many benchmarks. > Once you've built a runtime in which I could implement a JS runtime that's as performant as yours I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
  - mistercow 13y ago
    I'm just not convinced that something like CoffeeScript would benefit technically from compilation to a different target than JS. When the purpose of a language is simply to have all the features of another language, but with nicer syntax, what is to be gained from rebuilding all of those features from scratch? The one quasi-counterexample I can think of in that subset of languages is Objective-C which essentially just adds sugar on top of C and can be transformed relatively simply to C (there are library functions you can use to build classes and objects and call methods from scratch, using no actual Objective-C syntax). My understanding is that Objective-C compilers don't go through C as an intermediate, but this is merely to reduce compiling time, not to improve efficiency at runtime. If Objective-C did target C instead, the end result would be identical.
  - vidarh 13y ago
    So in other words, you are defining away most of what drives technology decisions. That makes it totally uninteresting to try to meet your constraint. We pretty much never try to implement a maximally efficient runtime architecture, cost or resources be damned. By this argument, there's no direct technical reason why we should not spend 20 years hand writing machine code and proving the code sequence optimal for each target architecture.
marshray 13y ago
"Maintaining compatibility with existing browsers" is like saying "emitting machine code for CPUs that actually exist".
- pbsdp 13y ago
  Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.
  - gmac 13y ago
    Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
    - pbsdp 13y ago
      > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
      - klibertp 13y ago
        asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
        rational_indian 13y ago
        Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
  - gnaritas 13y ago
    Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.

by pbsdp 13y ago

mistercow 13y ago

Can you explain specifically what you mean by a "direct" vs. an "indirect" technical reason?

pbsdp 13y ago
Direct: Constraints/requirements directly related to implementing a maximally effecient runtime architecture. Indirect: Market constraints that drive technical limitations. When it comes to browsers, Mozilla both creates and exists within market constraints that drive indirect technical reasoning. Lashing your industry to JS for another 10 years as a bytecode target is clearly not an optimal long-term solution as compared to the current state of the art, but it might make sense as a legacy support mechanism given the indirect technical constraints.
- azakai 13y ago
  > compared to the current state of the art What do you consider the current state of the art?
  - pbsdp 13y ago
    JVM, CLR, Mono AOT complation, NaCL/PNaCL. A future in which we wind up with architectural support for NaCL-style sandboxing intrinsics, in the same way we saw them be developed for VT-(x|d). Sticking us with JS for another decade and expecting us to compete against better application runtimes? No.
    - azakai 13y ago
      Those examples are all very different. What is your goal - speed? Code size? Portability? Security? Those examples don't all achieve those to the same degree, and I would argue that modern JS VMs are competitive with them in many respects.
      - pbsdp 13y ago
        > What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the state of the art. > ... and I would argue that modern JS VMs are competitive with them in many respects But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg. Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing. Let language authors target the low-level machine, and target your high-level general purpose bytecode. Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.
        azakai 13y ago
        JS VMs make tradeoffs, yes. Regarding your specific examples: 1. Shared-state multithreading. This has been proposed by various people in the past, and is still being debated. There are people for it and against it in various places. It might happen, if there is consensus to standardize it. 2. SIMD: PNaCl (which I mention since you mention NaCl in that context) does not have SIMD. But of course it can add SIMD, just like Mono and Dart have, and there is a proposal for JS as well, hopefully that will get standardized. So even those limitations are in principle resolvable. They do depend on standardization, of course, but so would any VM you want to run on the web. > Let language authors target the low-level machine, and target your high-level general purpose bytecode. asm.js is meant to get performance similar to a low-level machine. It's already very close to native on many benchmarks. > Once you've built a runtime in which I could implement a JS runtime that's as performant as yours I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
- mistercow 13y ago
  I'm just not convinced that something like CoffeeScript would benefit technically from compilation to a different target than JS. When the purpose of a language is simply to have all the features of another language, but with nicer syntax, what is to be gained from rebuilding all of those features from scratch? The one quasi-counterexample I can think of in that subset of languages is Objective-C which essentially just adds sugar on top of C and can be transformed relatively simply to C (there are library functions you can use to build classes and objects and call methods from scratch, using no actual Objective-C syntax). My understanding is that Objective-C compilers don't go through C as an intermediate, but this is merely to reduce compiling time, not to improve efficiency at runtime. If Objective-C did target C instead, the end result would be identical.
- vidarh 13y ago
  So in other words, you are defining away most of what drives technology decisions. That makes it totally uninteresting to try to meet your constraint. We pretty much never try to implement a maximally efficient runtime architecture, cost or resources be damned. By this argument, there's no direct technical reason why we should not spend 20 years hand writing machine code and proving the code sequence optimal for each target architecture.

marshray 13y ago

"Maintaining compatibility with existing browsers" is like saying "emitting machine code for CPUs that actually exist".

pbsdp 13y ago
Introducing a browser bytecode and/or sandboxing is not anywhere near the scale of complexity and expense of inventing a new CPU architecture. It's a policy decision, not a technical decision.
- gmac 13y ago
  Replacing JS may not be technically difficult, but practically it's extremely difficult (IE6, anyone?). Plus JS has got so fast, it's becoming hard to see the point anyway.
  - pbsdp 13y ago
    > Plus JS has got so fast, it's becoming hard to see the point anyway. Native is faster. A lot faster. And that's what browser apps are competing against.
    - klibertp 13y ago
      asm.js ? It's essentially almost typed intermediary language which can be directly/easily translated to CPU instructions.
      - rational_indian 13y ago
        Not fast enough apparently: https://developers.google.com/native-client/ https://developers.google.com/native-client/
- gnaritas 13y ago
  Getting your bytecode working in shipping in all browsers has proven to be impossible; there's a reason people compile to Javascript, it's the only practical choice.