11 ms·
> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself
by skatepark 14y ago
> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself.-
Er, so?
> One could argue quite successfully that one of the chief reasons Java (applets) in a browser is a bad design is because of its "standardised" bytecode format, which is what everyone in this discussion thread is screaming for.
Then please, reasonably argue it. I don't understand how the argument applies.
Java applets perform poorly in the browser for a number of reasons, none of which have anything to do with bytecode:
- Java's generational GC is designed around reserving a very large chunk of RAM, and performs poorly if insufficient RAM is reserved. This is a terrible idea for desktop software.
- Java's sandboxing model is broken and insecure, as it exposes an enormous amount of code as an attack surface. A bug in just about any piece of code in the trusted base libraries can result in a total sandbox compromise.
- Java is slow to start and slow to warm up, and applets more so. It historically ran single-threaded in the browser and blocked execution as it did start up.
- Swing does look native, and doesn't look like the web page, either. Applets can't actually interface with the remainder of the DOM in any integrated fashion (eg, you can't have a Java applet provide a DOM element or directly interface with JS/DOM except through bridging), so applets are odd-men-out for both the platform, and the website they're on.
> Flash was able to get by better by virtue of having a monopoly instead of a standard, and thus, has the freedom to change its swf format and bytecode format.
That doesn't even make sense. Flash was better because it didn't lock up your browser when an applet started, and didn't consume huge amounts of RAM due to a GC architecture that was poorly suited to running on user desktops.
Flash sucked because of its extremely poor implementation and runtime library design.
- TheZenPsycho 14y agoActually 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.
- TheZenPsycho 14y agoI saw your post before you deleted it. I didn't get a chance to respond before. I just wanted to say that you probably know a lot more about VM's than I do, and I'll concede that. I don't really know for sure whether switching to a bytecode vm would be great or not for the browser. I know that doing /any/ change to "the web" is a huge uphill battle, and so the ecmascript committee has to make a lot of comprimises for pragmatism. In any case, worse is better, and in the real world we can't have the perfect computer system. Haven't you seen tron legacy?