Hacker News Reader

Comment by guygurari | Hacker News Reader

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.)

View on HN

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)

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.

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.

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.

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.

"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...

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.

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.

If you're just suggesting that we need to ship a common bytecode to browsers, then I agree.

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.

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.

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

Reply on news.ycombinator.com