That's partly why Douglas Crockford wrote his JS book, JavaScript: The Good Parts, to try and eke out a subset of the language that was better than the whole. But "better" is always subjective, so I think we'll have to live with "worse is better" for a while longer, if not indefinitely.
What would you think of WebAssembly becoming the de-facto?
Web-Assembly makes it easier to use a language of a shop's choice. While choice is often good, it doesn't solve the original problem of a common standard language in terms of what devs actually use.
Actually using JavaScript (JS) as an assembly language seems the better route to the same goal. JS client engines can then be optimized for that standard to get speed, but older or non-optimized clients can still "run" stuff, just not as fast.
In other words, define a JS sub-language/API as the "assembly" then optimize clients to run that sub-language faster. The engines may put functions common to the sub-language in front of the internal function-lookup hashes for speed, for example. You'd then get the same results as WebAssembly but not "break" old clients: they'd just run slower than the newer/optimized clients.
You're probably aware of asm.js, and that we actually started with what you described and moved to WebAssembly. Do you think that we're moving in the wrong direction, then?
