"hacking a solution for the web that would work much better on the desktop is definitely not something you want to do."
the important question being which desktop?
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.
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.
How's that different from Java or Flash or Silverlight or anything else that requires a "special plugin"?
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).
We may need a new word - these platforms fall on the "managed" side of the native/managed split, but on the "native" side of the web/native one.
I run Links+ (http://links.twibright.com/) on OpenBSD to access the WWW. I don't have X11 installed, as I find GUIs to be far too distracting. Do you know of any ``cross platform'' web apps that work well in my environment (besides HN, of course)?
Then it follows that devs shouldn't support, e.g., deaf users.
1) immediately update your users all at once. Supporting 5 versions of legacy code sucks and adds friction to iteration.
2)monetization. Ads are more acceptable online. Subscriptions have better lifetime value than single purchases. And piracy is prevented.
3) usage metrics are a lot easier.
Bonus: cross platform.
If we can roll some of those up into a native app framework on top of. Net or JVM people might go back. Where is the Scala on JVM equivalent of Ruby on Rails that makes writing desktop apps fun again? (Doesn't have to be scalar or JVM, in just sayin')
*sorry for the typos, I'm fat fingering this on a smartphone If