| > It's actually an anti-JavaScript animus. You just wrote that I "ignored" Google's NaCl and Pepper work. That is not true, and yet you didn't hold Google to account anywhere on this thread (or others) for "ignoring" opportunities such as asm.js which were latent in Emscripten (in spite of their commercial support for Mandreel-compiled CWS games). There's more to what you wrote than just anti-JS animus. But let's not get stuck on this dispute; let's be unstuck like JS :-P. > It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do. Look deeper. The market is responding to cost structures ultimately based on how hard it is to do PNaCl + Pepper vs. Emscripten + asm.js + (Web APIs that devs need anyway). This is not about "best tech" or "marketing" or "market power". (Firefox doesn't have Google's marketing budget, and we definitely do not have decisive market power, as Netscape and then IE did -- but neither does Chrome.) This is about "shortest path" or "worse is better" -- who gets adoption first with something "good enough" wins, and can keep winning if the good-enough thing keeps evolving and doesn't get stuck. JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better. Anyway, at the asm.js level, apart from syntax aesthetics, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc. /be |
I think we're in agreement there.
> JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.
Perhaps in disagreement there, especially when you're competing against Apple's user-first focus, and especially when I'm on the receiving end of being forced to use a JS-based stack as a developer. I do mean the full stack, too -- instruction level profiling, debugging, failure reporting, consistent performance profiles, the whole nine yards.
> Anyway, at the asm.js level, apart from syntax, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.
Well, as an implementor of systems software, I can't help but be wary that asm.js brings along with it the entire JS language and (in practice) web stack, too. It means that the likelihood that 'web' applications will ever be free of the enormous web stack is lowered, though alternative implementations (eg, NaCL) reduce some of that risk.
I guess we'll see how it goes.