> 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.
> 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 ...
... 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.
> 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.
Moving past JS/DOM/CSS is just not possible. Backwards compatibility is how Web technologies survive. There have been many attempts to try to redo the Web from the ground up: XHTML 2.0 for example. They did not succeed.
> 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.
And users do not care about the surface syntax of the bytecode. If there were some user-facing advantage to not using JS as the transport format, then sure, it might be worth not using it. But so far I've simply heard "I don't like JavaScript syntax". It's fine that you have that opinion, but it's not worth sacrificing backwards compatibility for it, since it doesn't matter to users.
Regarding shipping native ARM and x86 code alongside the fallback mechanism, I've already explained why that won't work: developers won't test against the portable version, so it might as well not exist. The Web will be locked into those hardware architectures for all time. That might be a cheap way to compete with native apps in the short term, but in the long term it is bad for hardware innovation. (For example, consider that, as azakai noted, ARM might not have taken off at all if we had done that early on.)
> 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.
It only matters to a small subset of developers. Besides, if you really don't like it, just write a converter that converts it to the mnemonics of your choice. It's really quite trivial.
By your logic, we shouldn't gzip executables, because
tools have a hard time reading gzipped assembly. But that's a silly argument: you just un-gzip them first. It's the same with asm.js. If your tool has a hard time reading asm.js, convert it to a "real" bytecode first.
Additionally, LLVM bitcode isn't really much better from a simplicity standpoint. As I already pointed out, the verifier and bitcode reader for LLVM is much larger than the asm.js verifier.
> 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.
Yeah. The fallback mechanism is it doesn't run at all. As I already explained, there are applications for which it is much better to actually run, despite reduced performance.
And "unusable" really is a stretch. There are many apps written in Emscripten that run just fine in current browsers. Like I already said, AAA games aren't everything.
Sigh. You web guys are completely blinded to the rest of the engineering universe. You actively oppose all attempts to do anything genuinely new, and then say "look! It never works!"
Meanwhile, the rest of us non-web people grow increasingly tired of even trying to contribute or explain anything, since every novel gets shut down. The end result is that you've created a perfect echo chamber of self-fulfilling prophesy -- the web technology stack remains stuck and broken, and you actually seem to like it that way.
I don't work on AAA games. I work on development tools and end-user applications, where having good tooling directly translates to better user experiences.
The fact that you think no-compromises performance is only the purview of AAA games is exactly why you have no business being an OS vendor. I hope -- for the sale of our industry -- that Apple, Google, and Ubuntu eat Firefox OS' lunch.
> Sigh. You web guys are completely blinded to the rest of the engineering universe. You actively oppose all attempts to do anything genuinely new, and then say "look! It never works!"
I oppose technologies (such as PNaCl) that I feel are worse than alternatives (asm.js). The reason they are worse is that they are not backwards compatible.
> The fact that you think no-compromises performance is only the purview of AAA games is exactly why you have no business being an OS vendor. I hope -- for the sale of our industry -- that Apple, Google, and Ubuntu eat Firefox OS' lunch.
I never said that no-compromises performance is only the purview of AAA games. I said that for most applications that are not AAA games, running more slowly is better than not running at all.
The problem with opposing improved technologies is, simply put, that JS/DOM/CSS/HTTP are broken crufty accidents of design, and enforcing compatibility with them forever is what has prevented the web from moving forward, has stifled innovation, and ultimately is why the web could lose the app war.
Imagine if we'd used a priviledged market position to religiously defend against the introduction of everything that wasn't backwards compatible with gopher? That's what you're doing to our industry today, and in that, you're almost as bad for our industry as Microsoft was bad for the web in the 90s.
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.