5 ms·
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
by 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 agoYou 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.