> JavaScript and HTML are a lot more bloat than machine language code written to the wire.
http://mozakai.blogspot.com/2011/11/code-size-when-compiling... suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web).
And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?
Ah, you mean client memory bloat, not transfer bloat (i.e. pageload time). That part was not very clear at all.
You still need a nontrivial runtime (a la PNaCl) if you're going to provide the sort of sandboxing guarantees for the code people want for code that runs without explicit user opt-in. Or is that a non-goal in your case? In that case, I'd like to understand the problem you're trying to solve, since it sounds different from the one JavaScript in web browsers is solving.
I agree that things like asm.js have a performance hit compared to just running an unsafe binary blob. So does PNaCl (though the hit there is different from the asm.js hit: it has somewhat faster steady-state, but worse startup performance). Again, if you're not talking about something that has the same safety guarantees as JS and PNaCl you're comparing apples to oranges.
I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?
There is a degree to which you can make anything do anything. Using JavaScript as bytecode is actually really easy if you don't care about performance whatsoever. And if you get together a group of smart people who try very hard for a long time, I'm sure you could even get it to have reasonable performance. Especially if the people writing the interpreter are talking to the people writing the compiler.
But why would you actually do that as a long-term solution? JavaScript isn't an ISA. It's not hard-coded into anything. You don't have to throw away all the existing JavaScript code to start supporting something else in addition to it. All you would have to do is write code to support whatever bytecode you actually want to use and contribute it to the major browsers.
I came into this discussion many hours late, but I have to ask: Why are people discussing as if asm.js didn't exist?! It is fast. (It even support integers!)
To me, asm.js looks like a bad kludge -- and a great road ahead, just extend it a little bit over the next decade with the stuff compiler writers will clamor for.
What you're missing is that there is no need to do that. Using JavaScript as an intermediary representation for other languages on a permanent basis is kind of ridiculous. Improving browser support for JavaScript-as-IR provides no benefit over adding support for a "real" IR and introduces superfluous complexity which is the enemy of both performance and security.
Compiling other languages to JavaScript is a tolerable transition mechanism while browsers that don't support something better are still popular, but trying to improve the ability of browsers to interpret compiled-to-JavaScript code from other languages is farcical -- if you're going to update the browser then update it to support something better than JavaScript, not to improve the performance of the horrible legacy transition kludge.
I don't disagree with anything you wrote, except the first sentence.
But I'm cynical about the possibility to get a new bytecode standard out, without e.g. MS sabotag... extending it. Half the value of asm.js should be that if there is a working system already in place, the motivations for such shenanigans lessens.
EEE wouldn't work here. That only works when you have overwhelming market share. Microsoft has basically no browser market share on mobile and even on the desktop they no longer have so much that developers can afford to ignore everything else.
The way to handle Microsoft in a situation like this is to ignore them. Support the same IR on Firefox, Chrome and Safari and then Microsoft can play along or go home. At that point the worst they could do is implement an extended version that allows sites made for all browsers to work with IE but then encourage developers to make sites using Windows-specific features that won't work on other platforms. That's effectively what they tried with Silverlight and you see how far that got them.
Writing in a language appropriate to the task is almost always the right tradeoff.