I do not necessarily think the web needs generic VMs to move forward, or that JS needs replacing (I happen to enjoy JS with all its quirks quite a lot). I do,

I do not necessarily think the web needs generic VMs to move forward, or that JS needs replacing (I happen to enjoy JS with all its quirks quite a lot). I do, however, think that such a transition is possible if the powers that be (Google, Mozilla et. al) could agree on a fairly consistent strategy. Yes, 2 VMs side by side would probably be needed for some time, but 10+ years? Surely pure JS VMs could be moved to plugin status and be phased out faster than that, especially since someone would just write a compiler that compiled JS to this byte code format. No, it wouldn't be as fast as a VM highly optimized for specific JS quirks, but it could probably suffice. > It would be akin to rewriting malloc. Custom mallocs has been written for many different purposes like for example demanding game engines. While certainly a complicated task, it has been done numerous times. > And even then, you still have to support JavaScript being written directly in HTML <script> tags, something no other language could enjoy. So every browser must include a JavaScript to (new VM) bytecode compiler. JavaScript will always be in a priviledged position. Why would <script> tags HAVE to contain JS? I see no reason why if we're changing to a generic byte code web, JS in <script> tags could be phased out as well. However, as I said, I actually like JavaScript and I think experiments of modernization like Dart are approaching the "problem" in the entirely wrong way. I only think that if we "had" to change up, it could be done without much degradation to the user experience if any at all. Some old sites would break, but really, who cares? If you could compile your javascript codebase to byte code and have it still work, every one would do that without much problem.