There have been plenty of works done in this area already. See WebSharper, Script#... just two of the many available in the .NET ecosystem.
ASM.js is about formalising a known-good subset of JS that can be guaranteed to be compatible across browsers and therefore prime territory for building compilers on top of.
JS is nothing more than an intermediate language; it is similar to MSIL, JVM Bytecode, ASM. The only difference is that it happens to have a slightly C-style syntax. This is merely a coincidence and does not change the fact that is still an intermediate language designed for the web. It is utterly crazy the world has persisted writing code in it for so long. It is the modern web day equivalent of writing code in Assembly language.
The market is speaking, and it's saying that JavaScript needs to go.
Besides, there are numerous proven VMs and runtimes that could either be used directly, or at least used as a model if a new system is needed. NaCl and PNaCl have already shown one much better approach that is possible. Your "10 years" estimate is not based on reality.
And frankly, no, I don't think any proper VM or runtime would ever end up as bad as JavaScript is today. No other language, aside from perhaps PHP, exhibits so many inherent, fundamental flaws. It would take significant effort (and ignorance) to duplicate the same degree of mistake and flaw.
2. The market isn't saying JavaScript needs to go, JavaScript skills are high in demand, more so than ever.
3. This is the crux of your misunderstanding. I agree it would be nice if browsers supported e.g. LLVM out of the box. But they don't. And for political reasons they won't. If a company as large and powerful as Google cannot push NaCl adoption at all in other browsers (and NaCl was announced in 2008, so we're already half way to 10 years), how will you get them to adopt $YourVMofChoice? This is where ASM.js really wins - it is a subset of JavaScript, so it already works in other browsers, albeit without the performance boost and it is much easier for browser vendors to implement support for ASM.js than it is a whole new VM. Being backwards compatible means more web developers are likely to use it which will put pressure on other browser vendors to implement it. No one is arguing that ASM.js is a better technical solution to the problem, but it is a much better practical solution to the problem.
4. So this is another thing. Most of the people who are against ASM.js seem to dislike JavaScript the language. But ASM.js would free you from JavaScript almost entirely. The only time you'd see it is when you're debugging the "bytecode", and surely human readable bytecode is nicer than whatever something like LLVM spits out? Anyway, it seems like slightly curious reasoning.
Flash? Silverlight? ActiveX?
This feels obtuse -- obviously JS today is faster than it's ever been, but we want native c performance out of it. Do you have a in-browser VM solution today that can do complex, GPU-powered full 3D on every platform?
Then your VM solution is already inferior to javascript and will need significant time, money and development to even catch up to javascripts current level of "fast".
(Using, of course, "game" performance as a benchmark for the vague term "fast")
>"The market is speaking, and it's saying that JavaScript needs to go.
What? How do you rationalize this? Every major browser supports it to their core and most are working on dramatic imporvements for their implementations. Every mobile device supports it natively. Every computer I've seen in the past decade supports it.
The market is speaking? Where? Where is the market speaking? What devices are without javascript?
What browsers don't support javascript?
I think you are confusing the "market" for "a small subset of a-typical vocal developers".
Is it faster than 5 years ago sure. But the amount of work on needs to do have good performances is just silly. Is it everywhere ? sure. But i've seen a lot of crazy JS demos , i'm running a decent machine ( Macbook pro) and sorry but most of the exemples i see have poor perfomances , and nothing close to native performances. So imagine a soft you need to use 6 hours a day , you'll feel the bad perfs , trust me.
So please let's stop saying javascript is fast, it is a lie. Speed is not something absolute , it is relative. It is slower than native and will always be. Native will always be easier to optimize too.
Doesnt mean we cant do anything in html5/js , just mean we cant do everything. And the more "special" feature one uses the less "compatible" the js app will be.
Now is ASM a good thing sure. But let's not fool people just to promote JS.
Its not a big pain but it would make my life easier!
Photoshop on a Chrome Pixel, for instance, makes a lot of sense.
The only thing I'm locked into is Chromium, and even that I can replace.
I'd like to add Chromium to your list.
And your answer is... that... "vendor lock-in"?
I'm sorry, but you're making zero sense.
It's one more example of throwing in yet another layer when every other layer has proven to be insufficient.
And it's another example of trying to once again twist JavaScript into something it isn't very good at doing.
Once again, like so many web technologies before it, this will cause waste for years to come. There will be a huge waste of time for users who sit there waiting for slow code to execute. There'll be more wasted time and effort for developers stuck dealing with the messes that this will create.
It's clear that a proper VM of some sort would be useful in today's browsers. Trying to build this upon some awful subset of JavaScript is not the right way to do it.