8 ms·

> Based on the information available so far, it sounds like a very unappealing platform for developers. As a developer, you're essentially stuck using HTML, CSS

by azakai 14y ago

> Based on the information available so far, it sounds like a very unappealing platform for developers. As a developer, you're essentially stuck using HTML, CSS, and JavaScript. Saying you are stuck with JS is like saying iOS developers are stuck with ARM. Yes, underlying it all is ARM or JS on the respective platforms, but you can compile many other languages into those two: C#, C++, etc.

pifflesnort 14y ago
Elevating JavaScript to the pantheon of machine code ignores two simple and incontrovertible facts: - JavaScript is significantly slower than ARM (even if you cheat and reference asm.js) - JavaScript is not machine code.
- azakai 14y ago
  > - JavaScript is significantly slower than ARM How much slower, in your opinion?
  - pifflesnort 14y ago
    I don't see how opinion factors into this. Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that defines a machine translatable byte-code, coupled with a proprietary runtime to do the translation. They estimate 10x slower without that proprietary translation. That's a ridiculous waste of resources, especially on battery-powered devices.
    - azakai 14y ago
      > Mozilla estimates a best case of 2x slower than native with asm.js No, it's ~2x slower with the early prototype. It will get significantly faster than that. > a proprietary runtime The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js. > That's a ridiculous waste of resources, especially on battery-powered devices. ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
      - pifflesnort 14y ago
        > No, it's ~2x slower with the early prototype. It will get significantly faster than that. And we just need hardware XML accelerators and then XML will be great. This is not a new refrain from people who promote a subpar technology stack. Quality is just around the corner! We swear! I'll believe it when I see it, and I'll be happy, because it'll mean that we're finally that much closer to the next step of dropping JavaScript as a first-order target entirely. > The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js. It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. The bytecode is an inefficient ASCII representation which happens to be interpretable as JS, but can't be interpreted as JS to actually be implemented efficiently -- which is to say, it's not really useful JS at all. You may as well write a shell-script based ARM interpreter and call your ARM assembly "shell script". True, in a fashion, but also a totally pointless distinction. Everybody else will just call it "slow". > ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point. Android has the NDK for a reason, and even they are starting from a better position than trying to eek out runtime+rendering performance from an in-browser bytecode. Maybe on the web we'll get NaCL to serve the same purpose. It'll be great if it all works out and we wind up with a cross-platform efficient and useful development target, with robust view management and event systems and common widget toolkits. Of course, at that point the web will look pretty much like the application development environments that we've been targeting for decades: operating systems.
        azakai 14y ago
        > It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it. It is also, in addition, optimizable like a low-level VM. > Maybe on the web we'll get NaCL to serve the same purpose. asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?

by azakai 14y ago

pifflesnort 14y ago

Elevating JavaScript to the pantheon of machine code ignores two simple and incontrovertible facts: - JavaScript is significantly slower than ARM (even if you cheat and reference asm.js) - JavaScript is not machine code.

azakai 14y ago
> - JavaScript is significantly slower than ARM How much slower, in your opinion?
- pifflesnort 14y ago
  I don't see how opinion factors into this. Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that defines a machine translatable byte-code, coupled with a proprietary runtime to do the translation. They estimate 10x slower without that proprietary translation. That's a ridiculous waste of resources, especially on battery-powered devices.
  - azakai 14y ago
    > Mozilla estimates a best case of 2x slower than native with asm.js No, it's ~2x slower with the early prototype. It will get significantly faster than that. > a proprietary runtime The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js. > That's a ridiculous waste of resources, especially on battery-powered devices. ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
    - pifflesnort 14y ago
      > No, it's ~2x slower with the early prototype. It will get significantly faster than that. And we just need hardware XML accelerators and then XML will be great. This is not a new refrain from people who promote a subpar technology stack. Quality is just around the corner! We swear! I'll believe it when I see it, and I'll be happy, because it'll mean that we're finally that much closer to the next step of dropping JavaScript as a first-order target entirely. > The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js. It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. The bytecode is an inefficient ASCII representation which happens to be interpretable as JS, but can't be interpreted as JS to actually be implemented efficiently -- which is to say, it's not really useful JS at all. You may as well write a shell-script based ARM interpreter and call your ARM assembly "shell script". True, in a fashion, but also a totally pointless distinction. Everybody else will just call it "slow". > ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point. Android has the NDK for a reason, and even they are starting from a better position than trying to eek out runtime+rendering performance from an in-browser bytecode. Maybe on the web we'll get NaCL to serve the same purpose. It'll be great if it all works out and we wind up with a cross-platform efficient and useful development target, with robust view management and event systems and common widget toolkits. Of course, at that point the web will look pretty much like the application development environments that we've been targeting for decades: operating systems.
      - azakai 14y ago
        > It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it. It is also, in addition, optimizable like a low-level VM. > Maybe on the web we'll get NaCL to serve the same purpose. asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?