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