Hacker News Reader

Comment by jerf | Hacker News Reader

Choice of language to compile into the VM.

As for why not the Java VM, my guess is that the browsers are staggeringly enormous piles of C++ code and trying to integrate a Java VM into it would probably be insanely difficult, and anything other than pure 100% integration, too slow to use. It is probably literally easier to continue with the already-integrated JS VM and improve it up to JVM-esque quality than to try to graft the JVM into the browsers that exist today.

Or somebody would have already have tried since nothing would have prevented JS from already running on the JVM, if that were feasible; asm.js is actually independent of this question when it comes down to it.

View on HN

You know tons of language already compile and run on the JVM, right?

And you know the JVM ran in the browser almost 20 years ago, on hardware with a fraction of the CPU and memory resources we have today?

> You know tons of language already compile and run on the JVM, right?

Yes. So?

> And you know the JVM ran in the browser almost 20 years ago,

And it did such a good job that everyone has been prefering java applets to html/js/flash for those 20 years.

Oh, actually, they didn't. In fact, with few exceptions, they have been rejected by users for most of those 20 years. The implementation was horrible. I don't know if it's better today - maybe it is for some Windows browsers. But no browser on my Mac or Linux supports it without an external install -- and last time I actually used it (~2 years ago), it still took forever to start applets.

It might have worked if the execution was acceptable; it's not impossible - flash had reasonable execution which lead to widespread adoption that is still nontrivial despite a big part of the web - that of mobile - made it unusable. And yet, 18 years later (I'm up-to-date as of 2 years ago), Java applets are still a mess.

So, the bottom line is: who cares the JVM ran in the browser?

The applet user experience is horrible, you're right. It's pathetic that this hasn't been fixed.

Instead, we're developing apps on a platform intended for delivering documents, and targeting code to a "bytecode" (asm.js) built on a half-baked language originally intended for doing form validation, pop-up ads, and animating dancing bears.

I can play that game too:

Java and the JVM form a 3/4 baked language environment originally designed to run on washing machines, freezers and TV-top sets - that after 20 years can't even get applets and GUI properly.

See how easy it is?

Yes, I completely dislike JavaScript. I also completely dislike Java. But both are here to stay, regardless of their (lack of) merits compared to some ideals. Java missed the browser bus because it was horrible, and JavaScript drives the bus now because it was there.

Does this count? http://download.oracle.com/otndocs/products/javafx/2/samples...

Hah. I totally agree. I personally dislike both Java and Javascript, also. Javascript was born brain damaged. Java had a chance, but it jumped the shark sometime in the early 2000's when J2EE took off.

The JVM does not run in the browser. Its windows can run physically "in" the browser window, inasmuch as it would appear that the Java app was "in" the browser, but the Java app itself was a "plugin", and was a separate OS process. That's not the right kind of "in".

The JVM has never run in the same process as the browser, to the best of my knowledge, with the exception of the ill-fated "HotJava" browser: http://en.wikipedia.org/wiki/HotJava which ran Java applets "in" the browser by virtue of being written in Java, instead of C++. At the time this was too sluggish for general use, though.

So allow me to repeat myself: We can't run the JVM in the browser right now. The impedance mismatch between the JVM and the C++ world are just too great to have sufficient performance right now. All the current browsers are enormous piles of C++ code. There is no way to "just" integrate a JVM directly into them, and no bridge between the two is going to have enough performance for the demands we're putting on browsers. It doesn't matter how awesome Java may or may not be when the browsers aren't in Java. It's not an option today, short of replicating Sun's feat and rewriting your own browser in Java. But the only thing stopping you from doing that is the sheer size of the task, rather than any technical problem. (But make no mistake, it is an enormous undertaking now to write an engine capable of replacing any of the existing ones for even a single well-chosen use case.)

Oh, I see. I misunderstood your use of the word "in".

Reply on news.ycombinator.com