Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM? It would serve them absolutely no purpose to load dart (or JS) programs as text, compile that into bytecode, only to then translate that to native instructions. The only advantage would be in the case of having the dart source pre-compiled into bytecode by the programmer -- but at that point you are exposing it for other languages, and it would mean the complete opposite of what this article is saying.
> Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM?
They are right in calling V8 a VM. Your right too there is no need to have a bytecode befor going to native. Its however pretty comon thing to do. I think its a good idea if a VM builds a good bytecode befor running and I didnt thing about the direct way.
(Node: V8 sometimes has intermediate steps. Read this: http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-com...)
> It would serve them absolutely no purpose to load dart programs as text, compile that into bytecode, only to then translate that to native instructions.
Im sorry this is just wrong. To first build a bytecode out of all your code can be a good idea. LuaJit for example always builds bytecode befor going to native. Pretty comon thing to do.
It skipped my mind that Dart is also planned to be a server side language, in which case a bytecode might be useful to skip part of the compilation process on repeated runs. Either way, there has been no word on any of this from the Dart people or Google as far as I know, so I just find your confidence that they will take this approach a bit surprising never the less.
* They even do so on the homepage of the project: http://code.google.com/p/v8/