5 ms·

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve

Exactly. I never understood why the web community decided to re-invent this wheel. We started with a model for text publishing (HTML), and are trying to evolve it to allow full blown apps. If browsers simply supported the JVM as the browser execution environment, instead of implementing their own javascript engines, we'd have: 1. More language independence 2. Great performance for games, video (think implementing codecs without the need for browser support), and for crazy things like this. 3. Most importantly, the ability to run actual desktop-like apps in the browser at near-native speeds, instead of the mess that is currently required to get web apps to behave like desktop apps. (Nowadays Rails and friends are hiding most of this mess, but it's still there.)

mythz 15y ago
Have you never used Java Applets? (i.e. JVM in the browser) the load time alone makes that a terrible idea. Not too mention the 'breaking the web/page model' and poor UX that ensued. Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.
- rbranson 15y ago
  While I don't think the JVM is the savior, applets are a far cry from a good example. Applets usually cause the browser to lazy load the entire JVM as a plug-in, from scratch. Very little effort has been put forth to make this process fast. It's likely if the JVM was directly integrated, it would remain resident.
- guygurari 15y ago
  I have used and written applets, and they are horrible, but it's not what I'm suggesting. Applets run in their own area on the page and can't interact with the rest of the page like javascript does. I'm suggesting to replace the javascript runtime with a JVM runtime, while supporting everything javascript does through an API. Here's the use case I'm imagining: 1. When a user starts loading a page (read 'web app') the browser spawns a new JVM for that page. How long does this take? You can bring it down to the price of a fork if you keep a JVM running at all times. 2. Instead of running javascript that's embedded in the page, you compile and run Java/JRuby/Jython. Better yet -- have the server precompile the embedded code and send you the bytecode. Load it dynamically into the JVM and run it in the page's thread. With a modern JVM you get JIT for free and the code runs at near-native speeds. 3. Want long-running background tasks? No problem -- the JVM code can start its own threads. Suddenly AJAX, and all the other stuff we use to make web apps behave like desktop apps becomes trivial. 4. User leaves the page / web app? Kill the JVM.
  - Jeema3000 15y ago
    "Applets run in their own area on the page and can't interact with the rest of the page like javascript does." You can actually call methods in a Java applet from Javascript and vice-versa. It just doesn't seem to be used very much: http://download.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html http://download.oracle.com/javase/tutorial/deployment/applet...
  - rbranson 15y ago
    You seem highly optimistic about the JVM's appropriateness here. In reality what the browser needs is something more like the Dalvik VM, which is designed for compactness, efficiency, and multi-process models.
rbranson 15y ago
Seriously? the JVM? You listed the pros, but what about all the cons? Modern JVMs are fast, but highly specialized for long-running applications, which web pages are decidedly not. That's just the tip of the iceberg.
- guygurari 15y ago
  Yes, seriously. In what sense are JVMs "specialized for long-running applications"? If you mean they start slowly, that's hardly the case even if you start from scratch: > time java HelloWorld Hello, World! java HelloWorld 0.28s user 0.06s system 135% cpu 0.248 total In any case, the JVM is just an example (although I still argue it can serve this purpose well). My main point is that the "correct" model for the web is a bytecode-running VM inside every browser that lets you do everything javascript does through APIs.
  - rbranson 15y ago
    If you're just suggesting that we need to ship a common bytecode to browsers, then I agree.
  - delackner 15y ago
    Seriously? .28s is 280 milliseconds, for a result with zero content. That is already at the outside acceptable threshold for being perceived as slow response, and that's before we spend any time at all rendering the page. Certainly a VM of some kind could boot faster, but milliseconds count.
sehugg 15y ago
The applet model had/has major issues: * Takes way too long to load the JVM. Deal-breaker for many sites. * Horrible (AWT) and complicated (Swing) UI toolkits that ignored any look-and-feel parity with the rest of the web site or even the web browser itself. * The environment is controlled by Oracle. I don't think they're looking to compete with JS, Flash and Silverlight. Thus web applets (except for niche internal apps) are dead, RIP.
- guygurari 15y ago
  Applets are terrible but it's not what I'm suggesting. See my reply to mythz.
neopanz 15y ago
Agreed. And for those who pull the Java applet as the perfect counter-example, they need to ask themselves: does it take this long to start an Android app? Of course not! Because you can use the JVM in many different ways to eliminate the load time. In a way, one could imagine Android has a better example of how to mix OS/Web/Multi-Architecture(CPU)

mythz 15y ago

Have you never used Java Applets? (i.e. JVM in the browser) the load time alone makes that a terrible idea. Not too mention the 'breaking the web/page model' and poor UX that ensued. Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.

rbranson 15y ago
While I don't think the JVM is the savior, applets are a far cry from a good example. Applets usually cause the browser to lazy load the entire JVM as a plug-in, from scratch. Very little effort has been put forth to make this process fast. It's likely if the JVM was directly integrated, it would remain resident.
guygurari 15y ago
I have used and written applets, and they are horrible, but it's not what I'm suggesting. Applets run in their own area on the page and can't interact with the rest of the page like javascript does. I'm suggesting to replace the javascript runtime with a JVM runtime, while supporting everything javascript does through an API. Here's the use case I'm imagining: 1. When a user starts loading a page (read 'web app') the browser spawns a new JVM for that page. How long does this take? You can bring it down to the price of a fork if you keep a JVM running at all times. 2. Instead of running javascript that's embedded in the page, you compile and run Java/JRuby/Jython. Better yet -- have the server precompile the embedded code and send you the bytecode. Load it dynamically into the JVM and run it in the page's thread. With a modern JVM you get JIT for free and the code runs at near-native speeds. 3. Want long-running background tasks? No problem -- the JVM code can start its own threads. Suddenly AJAX, and all the other stuff we use to make web apps behave like desktop apps becomes trivial. 4. User leaves the page / web app? Kill the JVM.
- Jeema3000 15y ago
  "Applets run in their own area on the page and can't interact with the rest of the page like javascript does." You can actually call methods in a Java applet from Javascript and vice-versa. It just doesn't seem to be used very much: http://download.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html http://download.oracle.com/javase/tutorial/deployment/applet...
- rbranson 15y ago
  You seem highly optimistic about the JVM's appropriateness here. In reality what the browser needs is something more like the Dalvik VM, which is designed for compactness, efficiency, and multi-process models.

rbranson 15y ago

Seriously? the JVM? You listed the pros, but what about all the cons? Modern JVMs are fast, but highly specialized for long-running applications, which web pages are decidedly not. That's just the tip of the iceberg.

guygurari 15y ago
Yes, seriously. In what sense are JVMs "specialized for long-running applications"? If you mean they start slowly, that's hardly the case even if you start from scratch: > time java HelloWorld Hello, World! java HelloWorld 0.28s user 0.06s system 135% cpu 0.248 total In any case, the JVM is just an example (although I still argue it can serve this purpose well). My main point is that the "correct" model for the web is a bytecode-running VM inside every browser that lets you do everything javascript does through APIs.
- rbranson 15y ago
  If you're just suggesting that we need to ship a common bytecode to browsers, then I agree.
- delackner 15y ago
  Seriously? .28s is 280 milliseconds, for a result with zero content. That is already at the outside acceptable threshold for being perceived as slow response, and that's before we spend any time at all rendering the page. Certainly a VM of some kind could boot faster, but milliseconds count.

sehugg 15y ago

The applet model had/has major issues: * Takes way too long to load the JVM. Deal-breaker for many sites. * Horrible (AWT) and complicated (Swing) UI toolkits that ignored any look-and-feel parity with the rest of the web site or even the web browser itself. * The environment is controlled by Oracle. I don't think they're looking to compete with JS, Flash and Silverlight. Thus web applets (except for niche internal apps) are dead, RIP.

guygurari 15y ago
Applets are terrible but it's not what I'm suggesting. See my reply to mythz.

neopanz 15y ago

Agreed. And for those who pull the Java applet as the perfect counter-example, they need to ask themselves: does it take this long to start an Android app? Of course not! Because you can use the JVM in many different ways to eliminate the load time. In a way, one could imagine Android has a better example of how to mix OS/Web/Multi-Architecture(CPU)