> Come on, really? If you require a full spec to define a very specific format, type annotations, and special designators to actually take advantage of it in any meaningful way, it's not an "implementation detail", because as the user, I have to care about it.
First of all, it doesn't require a spec. We could have just done some heuristical optimizations like all JS engines have been doing since 2008, finding more cases where we can optimize and so forth - in fact, this was my initial idea for how to do this, as I mentioned earlier.
But we did decide to write a spec because (1) we want to be 100% open about this, and a spec makes it easier for others to learn about it, and (2) it helps us check we didn't miss anything because we have a formal type system.
>> So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth).
> That's exposing implementation details, too, and demonstrates a failing of JS.
If so, then that exposes a failing of all JITs, including the JVM. All optimizing implementations expose details. People have optimized for the JVM for years.
If you can't stand anything between you and the underlying CPU, then nothing portable (like JavaScript, C#, Java, etc.) will satisfy you. Actually even a CPU might not, because CPUs also optimize in unpredictable ways, these same issues are dealt with on that level too.
Again, there is room for native apps. But there is also room for portable, standards-based apps. The web is the latter.
> Apple and NeXT navigated these waters successfully for multiple decades via Mach-O and CFM fat binaries, and toolchains built around easily and efficiently supporting multiple architectures
I do see your point, but that isn't quite the same. Apple fat binaries were of a platform Apple controlled. We are talking about the web, which no one controls. But again, yes, to some degree it is possible as you say to overcome such issues.
> The web is competing with native applications. Now you're trying to compete with native operating systems, yet you're not willing to take the steps necessary to actually compete.
I disagree. If we have 2x slower than native now, and 1.5x slower than native later on, we're competitive with native on that front. And we have some advantages over native, like portability, which can have long-term performance advantages (for example, we can easily switch to a different underlying CPU if a faster arch shows up). There are also short-term performance advantages to things like Firefox OS that only run web apps, like their graphics stack being much simpler than Android's or Linux's (you don't need another layer underneath the browser compositor, and can go right into GL).