| > This is about "shortest path" or "worse is better ... 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. |
I share some concern about Apple, but less so in this "post Apple" era (Google, Samsung, up-and-comers from China).
On asm.js, the subset is verified at parse time and also as needed at link time, so there's no taint of "full JS" -- yet. We do expect the heaps to cross-connect, and want that. It won't make the parts of JS you dislike live much longer, from what I can tell.
To be perfectly candid, my goal is to evolve standardized JS, and therefore its implemented and widely distributed VMs, to be a good multi-language target language (and runtime).
This is eminently doable and closer than many people think. If it succeeds, then JS-the-handcoded-source-language can live or die on its (as evolved by then) language merits, and I won't cry if it dies.
But I wouldn't bet on its fan base dropping it even if they can choose other languages.
/be