4 ms·

Actually I missed this before. Javascript runtimes are /not/ VMs- I don't think I've ever seen a javascript engine use a virtual machine. Ever. Do you have evid

Actually I missed this before. Javascript runtimes are /not/ VMs- I don't think I've ever seen a javascript engine use a virtual machine. Ever. Do you have evidence of this? (unless you mean in the sense that asm.js is treating the javascript runtime, as though it were a VM) as for arguments against bytecode VM's, how about http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/ http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122 http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo... Basically it comes down to this: It's easier and way more efficient to secure an untrusted program using a language grammar rather than a "bytecode verifier" and a few other things. your comments about Java and the DOM are demonstrable untrue http://docs.oracle.com/javase/tutorial/deployment/applet/manipulatingDOMFromApplet.html http://docs.oracle.com/javase/tutorial/deployment/applet/man...

skatepark 14y ago
> I don't think I've ever seen a javascript engine use a virtual machine. Ever. If you're very, very sure of yourself, it's a good time to check if you should be. I think you're confused about what a VM is: http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual_machines http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual... As it turns out, pieces of Flash's VM were open-sourced as Tamarin, and used to implement JIT for Mozilla's JavaScript VM: https://developer.mozilla.org/en-US/docs/Tamarin https://developer.mozilla.org/en-US/docs/Tamarin The approaches used to run JavaScript at reasonable speed are the same approaches that one uses to implement a "VM", because they are VMs. An AST converted for fast interpretation winds up looking like a bytecode, because it is a bytecode. If you dug into Mozilla's SpiderMonkey, you'd find this bytecode: https://developer.mozilla.org/en-US/docs/SpiderMonkey/Bytecodes https://developer.mozilla.org/en-US/docs/SpiderMonkey/Byteco... Yes. A bytecode. In Firefox's JavaScript VM. Now, you don't have to compile to an explicit bytecode. V8 and Nitro use an internal in-memory temporary interpretation of the AST, but compile it straight to machine code, and do not have a bytecode interpreter. There are advantages to this when all the world is sending around JS source code. There are disadvantages to sending around JS source code, which also happens to be why things like source minimizers exist. > your comments about Java and the DOM are demonstrable untrue http://docs.oracle.com/javase/tutorial/deployment/applet/man.. http://docs.oracle.com/javase/tutorial/deployment/applet/man.... No, because what I said was that Java was not a first-class DOM member "except through bridging", which is what you linked to there.

skatepark 14y ago

> I don't think I've ever seen a javascript engine use a virtual machine. Ever. If you're very, very sure of yourself, it's a good time to check if you should be. I think you're confused about what a VM is: http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual_machines http://en.wikipedia.org/wiki/Virtual_machine#Process_virtual... As it turns out, pieces of Flash's VM were open-sourced as Tamarin, and used to implement JIT for Mozilla's JavaScript VM: https://developer.mozilla.org/en-US/docs/Tamarin https://developer.mozilla.org/en-US/docs/Tamarin The approaches used to run JavaScript at reasonable speed are the same approaches that one uses to implement a "VM", because they are VMs. An AST converted for fast interpretation winds up looking like a bytecode, because it is a bytecode. If you dug into Mozilla's SpiderMonkey, you'd find this bytecode: https://developer.mozilla.org/en-US/docs/SpiderMonkey/Bytecodes https://developer.mozilla.org/en-US/docs/SpiderMonkey/Byteco... Yes. A bytecode. In Firefox's JavaScript VM. Now, you don't have to compile to an explicit bytecode. V8 and Nitro use an internal in-memory temporary interpretation of the AST, but compile it straight to machine code, and do not have a bytecode interpreter. There are advantages to this when all the world is sending around JS source code. There are disadvantages to sending around JS source code, which also happens to be why things like source minimizers exist. > your comments about Java and the DOM are demonstrable untrue http://docs.oracle.com/javase/tutorial/deployment/applet/man.. http://docs.oracle.com/javase/tutorial/deployment/applet/man.... No, because what I said was that Java was not a first-class DOM member "except through bridging", which is what you linked to there.