Why would we go this route? Why not just define a bytecode spec and be done with all of this nonsense? Mozilla is perfectly free to implement the bytecode by compiling it to a restricted subset of JS (in fact, it might make a lot of sense to do so). Defining a simple register or stack based machine and producing bytecode for it would greatly simplify the job of implementers, it would make defining the specification and determining compliance with the standard very straight forward, and it would let us eventually do web programming without being tied to a specific language.
"Why not just define a bytecode spec and be done with all of this nonsense?"
Because such bytecode would not be backwards compatible.
"Defining a simple register or stack based machine and producing bytecode for it would greatly simplify the job of implementers"
Let's take as a given that every browser that wants to implement asm.js needs a JavaScript parser (for JS content on the Web) and an asm.js compiler IR. The question, then, is whether it's simpler to write a verifier that simply walks over parse trees or whether it's simpler to write a reader for whatever custom bytecode is defined. I don't think that the verifier is much harder: the JS version of the verifier clocks in at just over 1,000 lines of code [1], which is nothing compared to the size of the VM as a whole. Certainly that 1,000 lines of code doesn't justify breaking backwards compatibility, in my mind.
"it would make defining the specification and determining compliance with the standard very straight forward"
The specification already more or less exists, and determining compliance is straightforward: 1,000 lines of code for the reference implementation.
"it would let us eventually do web programming without being tied to a specific language"
asm.js doesn't tie you to a language. On the contrary, it allows you to use alternative languages in order to get better performance than you would if you used normal JavaScript. JS is used as the transport format for backwards compatibility, nothing more. In fact, in SpiderMonkey, asm.js has its own set of IR opcodes (Asm*) that are separate from the JavaScript opcodes.
I don't know you, but I'm guessing you are somehow in love with javascript and invested in seeing it succeed.
The world is largely divided into two camps, the people who are in love with javascript and the people who think it is a sick joke. Those of us in the 'sick joke' camp would like to see javascript made optional to web programming, and not a part of our toolchain at all. If javascript is part of the toolchain at all, I will have to eventually debug javascript code, and javascript was written under the 'principle of maximum surprise' making it a very awful language to those of us who haven't based our careers on learning every single edge case (and every case is an edge case in javascript!)
The other half of the world is the 'javascript is great' people, and they usually learned to program with javascript or have spent a large portion of their coding career inside of it. They don't see what the big deal is, it's a perfectly good language, right? Well, it's actually a pretty gross language that has one amazing feature, it is available on every computer without having to install anything extra.
Please, let us have the OPTION of a completely javascript free web. The javascript fans can keep it, just give the rest us a choice.
> I don't know you, but I'm guessing you are somehow in love with javascript and invested in seeing it succeed.
I'm not. I just asked you two technical questions I was curious about, given what you said. If you had answered them, I might understand your position better.
I'm guessing you are somehow in love with javascript and invested in seeing it succeed.
In the discussions regarding asm.js I often see this tack taken by the folks who are opposed to it as a solution. Many people have an obvious hate-on for Eich and often Mozilla by extension. I will not accuse you of that.
As far as 'the principle of maximum surprise' goes, I would recommend trying to understand how the spec is designed to accomplish its goals.
As someone who is more in the second camp than the first (JS is something of a joke disguised as a language), actually, I see asm.js as a great way to eventually kill off Javascript. Whereas I see trying to specify -- and get all browsers to implement -- a whole new VM, as quixotic.
Although JS, warts and all, is no joke at this stage. It will die hard, but my hope is that JS VMs become multi-lingual in as good a way, or better, than the JVM and the CLR. Certainly better in terms of diversity of implementation, reach of the Web, and consequent interop testing in the large.
