Hacker News Reader

Comment by jbooth | Hacker News Reader

So here's my question, how come no browser has a way for a java applet to manipulate the DOM? We've got GWT compiling java to JS, we've got this compiling scala to JS.. and the JVM was originally built to run inside of a browser. Why can't we just close the circle? I guess people don't want their website visitors to see a "you must upgrade java" popup first thing?

View on HN

There was - it was called LiveConnect - but like most things to do with Java and the browser(s), it languished in a half-supported state, and really isn't worth thinking about any more.

As are applets - a great idea, implemented poorly, and now essentially lost to the annals of history.

Don't forget about websites from academia that implement certain proof-of-concepts; for some reason that commumity still keeps using applets.

We used to do it because dealing with cross-browser compatibility was a pain. For instance, I used to use a 1-pixel applet instead of XMLHttpRequest for AJAX (slightly before they coined the term "AJAX") and applets for rendering live-updated XML-based diagrams (instead of SVG) in both cases because it simply made things less buggy and less of a pain to support at the time. But that was in 2004 to 2007.

But once we've written something, and it works, we're often a little slow updating it to newer tech, because we can't write a paper out of "the same thing I published earlier, but now using SVG and XHR instead of applets".

If it still just-about works, there's less impetus to rewrite it.

There are quite a few applets demonstrating chemical reactions/bonds or physical equations etc., and as such applets are relatively common in teaching materials for high school (/secondary education) physics and chemistry, at least with teachers (I had or) I have substituted.

They are obviously years old and rarely signed, which is a shame because quite often there are plenty of demos, none of which I can run with modern default settings of a PC (and sometimes I wouldn't have enough credentials to do anything about it, anyway).

Why can't Python? Why can't Ruby? Why can't Perl?

Fundamentally, the languages able to run in the browser are only limited by what the browsers want to implement. It would be great if browsers could render QML, or could use <script type="text/python"> or <script type="text/scala"> or whatever but that requires browsers to either depend on an external JVM or include on in the browser. Or you need to put the QML runtime in the browser or as a dependency. Or you have to put a Python interpreter in the browser or as a dependency.

None of those languages have a secure sandbox and writing one is incredibly difficult, even for a language designed to run in such an environment (Java). Native Client might be interesting here to build sandboxes for other languages.

Lua was made with embedding in mind. You can start a VM with an empty global environment (no standard libraries etc..) but there is not a big benefit in jumping from js to lua because they are so similar.

The old Netscape Java Applet APIs supported dom manipulation:

http://www.java2s.com/Code/JavaScript/Development/UsingJavaS...

I believe that other browsers that supported applets supported these APIs as well.

I don't think that anyone really wants to bring back Java Applets, though.

Wasn't the JVM originally built to run inside of a toaster?

"Java was originally designed for interactive television, but it was too advanced for the digital cable television industry at the time."

Likely it was designed, and then used for their first product. Then when that failed, they kept the language for other possible targets.

http://www.oracle.com/technetwork/java/javase/overview/javah...

My guess is that Mozilla would never support it.

http://www-archive.mozilla.org/projects/blackwood/dom/

Reply on news.ycombinator.com