4 ms·

I've sometimes wondered whether you could solve those problems within a system that provided a more native experience. For example, consider a new kind of clien

by ssp 14y ago

I've sometimes wondered whether you could solve those problems within a system that provided a more native experience. For example, consider a new kind of client that would download and run bytecode instead of HTML/CSS/JavaScript. The bytecode would have a built-in abstraction layer over various platform facilities such as graphics and sound, allowing it to look and feel much more like a native application.

sophacles 14y ago
This was called java applets, then flash, then silverlight the last few times it was tried.
- ssp 14y ago
  It was also called "web browser" one of the last times it was tried. Those became quite popular I believe. Flash has done quite well actually, but one flaw is that it is completely tied to the web browser, so it doesn't provide a really native experience. AIR would be a better counter-example. Also, flash is quite unreliable. Java applets had an addtional problem in that they required a huge standard library and took forever to start up. I'd suggest instead to download the standard library on demand.
  - sophacles 14y ago
    "Web browser" downloads and runs compiled bytecode instead of html/css/javascript now (as the gp is suggesting)? Without a special plugin? Huh, news to me.
    - ryannielsen 14y ago
      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).
sciurus 14y ago
http://en.wikipedia.org/wiki/Java_Webstart http://en.wikipedia.org/wiki/Java_Webstart

by ssp 14y ago

sophacles 14y ago

This was called java applets, then flash, then silverlight the last few times it was tried.

ssp 14y ago
It was also called "web browser" one of the last times it was tried. Those became quite popular I believe. Flash has done quite well actually, but one flaw is that it is completely tied to the web browser, so it doesn't provide a really native experience. AIR would be a better counter-example. Also, flash is quite unreliable. Java applets had an addtional problem in that they required a huge standard library and took forever to start up. I'd suggest instead to download the standard library on demand.
- sophacles 14y ago
  "Web browser" downloads and runs compiled bytecode instead of html/css/javascript now (as the gp is suggesting)? Without a special plugin? Huh, news to me.
  - ryannielsen 14y ago
    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).

sciurus 14y ago

http://en.wikipedia.org/wiki/Java_Webstart http://en.wikipedia.org/wiki/Java_Webstart