3 ms·

I'd love to hear what you consider to be the significant difference between "bytecode" and "code". Compiling ASCII code down to bytecode or machine code doesn't

I'd love to hear what you consider to be the significant difference between "bytecode" and "code". Compiling ASCII code down to bytecode or machine code doesn't change semantics (not often significantly, at least); code is code. The browser is downloading and running code, and is offering an increasingly robust and attractive platform from which to do so. How's that different from Java or Flash or Silverlight or anything else that requires a "special plugin"?

sophacles 14y ago
From a semantics point of view: the post I originally replied to asked about compiled bytecode, not textual code. From a deeper point of view: Theoretically you are correct. But in practicalities... Peresumably you get 2 benefits from compiling the code to bytecode: * obfuscated source so people can't steal your secret sauce. * faster execution because the compile step is skipped. The second one has real practical limitations: for any major gain, the bytecode has to be in a format that allows fast execution, which usually includes taking out certain checks that can be done at compile time, taking advantage of lower level runtime stuff and in some cases, optimizations for the hardware arch below. This is all well and good, but when you have multiple engines interpreting the bytecode, this can be done in very different ways. In practice, to get from a robust bytecode to something that takes full advantage of the system, effectively invokes a second compile step from bytecode to the vm's internal representation. This is what a lot of JVMs do. I'm not sure anything would actually be gained in that case. Further, a robust bytecode format would required, since there are already piles of hacks in the JS libraries we all use to handle various browser differences. To get a bytecode that allows this, we end up with something that looks more like a simple source code transform than any bytecode that gives significant speedup out of the gate. (and at that point, your obfuscation of the code starts to go away too - you could just disassemble it to something that looks like jsmin output).

sophacles 14y ago

From a semantics point of view: the post I originally replied to asked about compiled bytecode, not textual code. From a deeper point of view: Theoretically you are correct. But in practicalities... Peresumably you get 2 benefits from compiling the code to bytecode: * obfuscated source so people can't steal your secret sauce. * faster execution because the compile step is skipped. The second one has real practical limitations: for any major gain, the bytecode has to be in a format that allows fast execution, which usually includes taking out certain checks that can be done at compile time, taking advantage of lower level runtime stuff and in some cases, optimizations for the hardware arch below. This is all well and good, but when you have multiple engines interpreting the bytecode, this can be done in very different ways. In practice, to get from a robust bytecode to something that takes full advantage of the system, effectively invokes a second compile step from bytecode to the vm's internal representation. This is what a lot of JVMs do. I'm not sure anything would actually be gained in that case. Further, a robust bytecode format would required, since there are already piles of hacks in the JS libraries we all use to handle various browser differences. To get a bytecode that allows this, we end up with something that looks more like a simple source code transform than any bytecode that gives significant speedup out of the gate. (and at that point, your obfuscation of the code starts to go away too - you could just disassemble it to something that looks like jsmin output).