What would a standardized bytecode bring to the table over asm.js?
To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers, and going with the latter sounds eminently reasonable to me. The x86 bytecode encoding is really ugly too (look at those one-byte-long binary coded decimal instructions), but the survival characteristics of backwards compatibility are undisputed...
> What would a standardized bytecode bring to the table over asm.js?
A better technical solution and lower development friction throughout the entire stack. The hackiness of the web already introduces an enormous amount of cumulative friction, and asm.js just adds more.
People have been asking for a solution -- and working on them -- for 5+ years, and Eich has consistently replied that such a thing is unnecessary. In many respects asm.js is an admission of defeat, in that it's not standard JavaScript (it's a strictly designed subset), and they are attempting to tune it to the purpose of providing a standard bytecode format, while still being able to claim that it is JavaScript.
In the same period of time, entirely new and proprietary mobile platforms have emerged and eaten a huge portion of the application market's mindshare and marketshare.
Perhaps it's time to stop listening to someone who can't think outside his own box, and instead choose a technology that is actually well-suited to the problemspace.
> To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers ...
That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform.
Human readable JavaScript "byte code"? Seriously? This is the kind of backwards thinking that left the door wide open for native mobile apps to own the market.
I would love to be able to target the web instead of proprietary platforms, but the technology stack isn't there and won't be as long as people like Eich are running the show, and remain fixated on what worked for web documents as the solution for what will work the future of web apps.
"In many respects asm.js is an admission of defeat"
Going with a worse-is-better solution for the purposes of backwards compatibility is always an admission of defeat. But it's a very practical one. It's an admission of defeat that has made Intel and Microsoft billions, for example.
"while still being able to claim that it is JavaScript."
But it is JavaScript. The ECMA-262 spec says how to interpret it.
"That could be achieved by generating JS from the bytecode, which would turn the problem into a temporary one that disappears as browsers are updated, instead of yet another time and resource draining wart on the web platform."
And then Web developers have to ship two binaries. Foisting the problem of backwards compatibility onto Web developers for the sake of making a nicer bytecode parser doesn't seem like a win to me.
To me the choice is between more convenient encoding format for the bytecode and backwards compatibility with all browsers, and going with the latter sounds eminently reasonable to me. The x86 bytecode encoding is really ugly too (look at those one-byte-long binary coded decimal instructions), but the survival characteristics of backwards compatibility are undisputed...