4 ms·

> Slow is not always "totally useless". It just degrades gracefully. Slow isn't graceful, especially when your competitors aren't slow. I look forward to Mozil

> Slow is not always "totally useless". It just degrades gracefully. Slow isn't graceful, especially when your competitors aren't slow. I look forward to Mozilla advertising Firefox as "only 10x slow as Chrome!". In this case, it's even worse, because if asm.js is successful, then the fallback mechanism will simply become an awkward vestigial limb that's no longer required by any modern browser. Treat a vestigial limb as your first-order target is silly. > Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks? Because it's about users, not about developers. Generating optimized binaries means that users have a better user experience. > Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle. "I'll pay you tomorrow for a hamburger today" is getting old.

pcwalton 14y ago
Slower is far better than not running at all. Backwards compatibility is how Web technologies (and, for that matter, most technologies--x86 for example) survive. And asm.js' encoding has no impact on the user experience. That's precisely my point. Using a binary bytecode instead of interoperable JS would maybe make the parsing easier, but that doesn't make up for the costs this would burden developers with (not to mention the difficulties with two VMs sharing data and so forth, something which is terribly important but is always glossed over in these conversations). Finally, regarding threads, we're talking about a new proposed standard here. There will always be work to do, since just taking the NDK and putting it on the Web is not an option. PNaCl isn't shipping yet. So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does.
- pifflesnort 14y ago
  > Slower is far better than not running at all. Why? For the purposes for which asm.js is intended, the code may as well not be running at all, and users will be driven to upgrade their browser. If you really want to support backwards compatibility, then make it a secondary target, not the primary one that you saddle yourself with for all time. > So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does. I believe NaCL and PNaCL provide a much saner path to an ultimately superior end, and would have a far greater chance of succeeding if Mozilla wasn't playing NIH to assuage their need to support JavaScript. asm.js is competing with native, and they're starting out with an intentional disadvantage.
  - pcwalton 14y ago
    > For the purposes for which asm.js is intended, the code may as well not be running at all, and users will be driven to upgrade their browser. That isn't true. Consider photo filters: you may want to have a photo filter written in asm.js for maximum performance on browsers that support it, but degrades to a suboptimal, but usable, experience on browsers that don't support it. Likewise, consider an asm.js-compiled mobile game: you may want it to be playable on desktops too, whose browsers generally contain enough horsepower to run JS-compiled mobile games at full speed even without special support for asm.js. There are plenty of use cases in which "slower but backwards compatible" is extremely desirable. AAA games are not everything. > If you really want to support backwards compatibility, then make it a secondary target, not the primary one that you saddle yourself with for all time. Again, it's not worth forcing Web developers to compile multiple binaries, when the main difference here is how you parse the bytecode. > asm.js is competing with native, and they're starting out with an intentional disadvantage. PNaCl is starting out with the same disadvantage as asm.js, modulo surface syntax. In fact, asm.js arguably has an advantage over PNaCl. Starting from the JS AST that must be constructed by every browser anyway, the asm.js verifier is a mere 1,216 lines. For comparison, LLVM's BitcodeReader is over 3,000 lines. LLVM's Verifier is over 2,000.
    - pifflesnort 14y ago
      > That isn't true. Consider photo filters: you may want to have a photo filter written in asm.js for maximum performance on browsers that support it, but degrades to a suboptimal, but usable, experience on browsers that don't support it. Likewise, consider an asm.js-compiled mobile game: you may want it to be playable on desktops too, whose browsers generally contain enough horsepower to run JS-compiled mobile games at full speed even without special support for asm.js. You're competing with native, not with today's crappy JS webapps. "Just like native but slow!" is not a selling point to users that have a plethora of better performing, better integrated native applications to choose from. You guys at Mozilla could just target NaCL/PNaCL, contribute asm.js as the second-tier means of pulling IE and Safari along with you, the whole industry moves past the disaster that is JS/DOM/CSS, and everyone is happier. > Again, it's not worth forcing Web developers to compile multiple binaries, when the main difference here is how you parse the bytecode. Again, it's ALL about users, not developers. Of course, it can be easy for developers too ... cc -arch armv6 -arch armv7 -arch i386 -arch pnacl -c users_first.c -o users_first.o ... but at the end of the day, you have to stop thinking about the developers as your primary users if you want to produce a successful platform. Developers matter -- but users are why we're all here. It's not as if Apple's users have been hurting because developers have to target multiple variants of ARM and learn a new programming language. > PNaCl is starting out with the same disadvantage as asm.js, modulo surface syntax That's not just surface syntax. As a tool maker, I spend an awful lot of time working on and with things that touch assembly/bytecode as "surface syntax". It matters, a lot, and JavaScript is a TERRIBLE bytecode syntax to have to deal with. That said, it's also not the same disadvantage, because PNaCL implementations compile to native code; there's no fallback interpretation mechanism that exhibits the unusable performance profile of asm.js's fallback profile. That said, I think asm.js would be a great second-tier target for PNaCL in the case that one wishes to target a backwards browser, regardless of how slow it is.

pcwalton 14y ago

Slower is far better than not running at all. Backwards compatibility is how Web technologies (and, for that matter, most technologies--x86 for example) survive. And asm.js' encoding has no impact on the user experience. That's precisely my point. Using a binary bytecode instead of interoperable JS would maybe make the parsing easier, but that doesn't make up for the costs this would burden developers with (not to mention the difficulties with two VMs sharing data and so forth, something which is terribly important but is always glossed over in these conversations). Finally, regarding threads, we're talking about a new proposed standard here. There will always be work to do, since just taking the NDK and putting it on the Web is not an option. PNaCl isn't shipping yet. So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does.

pifflesnort 14y ago
> Slower is far better than not running at all. Why? For the purposes for which asm.js is intended, the code may as well not be running at all, and users will be driven to upgrade their browser. If you really want to support backwards compatibility, then make it a secondary target, not the primary one that you saddle yourself with for all time. > So the question is whether asm.js presents a shorter, more straightforward path to success than the alternatives. I believe it does. I believe NaCL and PNaCL provide a much saner path to an ultimately superior end, and would have a far greater chance of succeeding if Mozilla wasn't playing NIH to assuage their need to support JavaScript. asm.js is competing with native, and they're starting out with an intentional disadvantage.
- pcwalton 14y ago
  > For the purposes for which asm.js is intended, the code may as well not be running at all, and users will be driven to upgrade their browser. That isn't true. Consider photo filters: you may want to have a photo filter written in asm.js for maximum performance on browsers that support it, but degrades to a suboptimal, but usable, experience on browsers that don't support it. Likewise, consider an asm.js-compiled mobile game: you may want it to be playable on desktops too, whose browsers generally contain enough horsepower to run JS-compiled mobile games at full speed even without special support for asm.js. There are plenty of use cases in which "slower but backwards compatible" is extremely desirable. AAA games are not everything. > If you really want to support backwards compatibility, then make it a secondary target, not the primary one that you saddle yourself with for all time. Again, it's not worth forcing Web developers to compile multiple binaries, when the main difference here is how you parse the bytecode. > asm.js is competing with native, and they're starting out with an intentional disadvantage. PNaCl is starting out with the same disadvantage as asm.js, modulo surface syntax. In fact, asm.js arguably has an advantage over PNaCl. Starting from the JS AST that must be constructed by every browser anyway, the asm.js verifier is a mere 1,216 lines. For comparison, LLVM's BitcodeReader is over 3,000 lines. LLVM's Verifier is over 2,000.
  - pifflesnort 14y ago
    > That isn't true. Consider photo filters: you may want to have a photo filter written in asm.js for maximum performance on browsers that support it, but degrades to a suboptimal, but usable, experience on browsers that don't support it. Likewise, consider an asm.js-compiled mobile game: you may want it to be playable on desktops too, whose browsers generally contain enough horsepower to run JS-compiled mobile games at full speed even without special support for asm.js. You're competing with native, not with today's crappy JS webapps. "Just like native but slow!" is not a selling point to users that have a plethora of better performing, better integrated native applications to choose from. You guys at Mozilla could just target NaCL/PNaCL, contribute asm.js as the second-tier means of pulling IE and Safari along with you, the whole industry moves past the disaster that is JS/DOM/CSS, and everyone is happier. > Again, it's not worth forcing Web developers to compile multiple binaries, when the main difference here is how you parse the bytecode. Again, it's ALL about users, not developers. Of course, it can be easy for developers too ... cc -arch armv6 -arch armv7 -arch i386 -arch pnacl -c users_first.c -o users_first.o ... but at the end of the day, you have to stop thinking about the developers as your primary users if you want to produce a successful platform. Developers matter -- but users are why we're all here. It's not as if Apple's users have been hurting because developers have to target multiple variants of ARM and learn a new programming language. > PNaCl is starting out with the same disadvantage as asm.js, modulo surface syntax That's not just surface syntax. As a tool maker, I spend an awful lot of time working on and with things that touch assembly/bytecode as "surface syntax". It matters, a lot, and JavaScript is a TERRIBLE bytecode syntax to have to deal with. That said, it's also not the same disadvantage, because PNaCL implementations compile to native code; there's no fallback interpretation mechanism that exhibits the unusable performance profile of asm.js's fallback profile. That said, I think asm.js would be a great second-tier target for PNaCL in the case that one wishes to target a backwards browser, regardless of how slow it is.