What that has to do with anything? The post I replied to said that "language neutral bytecode project neve worked" and brought up Parrot as an example. He was not specific to them not working for Javascript.
Now, besides off context, your comment is wrong in four ways:
1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages.
2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript.
3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too.
4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
JavaScript is very relevant because there is tons of legacy code that has to run equally as fast in this new bytecode VM as it runs today under the various engines. The choice of VM comes down to how well it works with dynamic languages. JVM and CLR are both modeled after statically typed languages. Microsoft spent quite a bit of money trying to put JavaScript on top of .NET but finally gave up, and today it places it's IE platform on equal footing with .NET.
Now, besides off context, your comment is wrong in four ways:
1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages.
2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript.
3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too.
4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.