Hi,

Towards the end of the talk, there was some discussion about the decision to compile JavaScript directly to machine code versus using an intermediate bytecode/language.

I think that one of the biggest differences in this case is the nature of how JavaScript itself is usually deployed and executed by clients. Being that V8 is targeted toward executing JavaScript that is usually already deployed somewhere on the web, it must expect that its input is JavaScript code. For better or for worse, JavaScript code is what is living out there on the web, and not some intermediate bytecode/language.

If there was more upfront control regarding the development and deployment of the code itself, it would probably make more sense to use some intermediate bytecode/language. I think that the big advantage to using an intermediate bytecode/language is not so much for the virtual machine, but really for the developer's experience while creating the code itself. It allows for easier/faster syntax checking, IDE features (code navigation, auto completion, etc), and to some extent can hide implementation details from an end user when it is deployed remotely.

Anyway, although this work is no doubt interesting, I can't help but wonder why we aren't pooling our efforts into generalizing more mature virtual machines (such as the JVM, etc.) instead of creating new and specialized ones like V8. The open nature of some VMs, such as the JVM, allow them to be slimmed down, generalized, and then tuned for different execution profiles (Java Server, Java Client, JavaScript, Python, etc), yet still take advantage of all the work that has already been devoted to these projects.