4 ms·

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 scal

by jbooth 12y ago

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?

deleted 12y ago
[deleted]
switchbak 12y ago
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.
- stingraycharles 12y ago
  Don't forget about websites from academia that implement certain proof-of-concepts; for some reason that commumity still keeps using applets.
  - exprE 12y ago
    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).
  - wbillingsley 12y ago
    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.
jsight 12y ago
The old Netscape Java Applet APIs supported dom manipulation: http://www.java2s.com/Code/JavaScript/Development/UsingJavaScriptinanApplet.htm 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.
lmm 12y ago
My guess is that Mozilla would never support it.
- icebraining 12y ago
  http://www-archive.mozilla.org/projects/blackwood/dom/ http://www-archive.mozilla.org/projects/blackwood/dom/
mjt0229 12y ago
Wasn't the JVM originally built to run inside of a toaster?
- giancarlostoro 12y ago
  "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/javahistory-index-198355.html http://www.oracle.com/technetwork/java/javase/overview/javah...
zanny 12y ago
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.
- electrum 12y ago
  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.
  - Gurkenmaster 12y ago
    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.

by jbooth 12y ago

deleted 12y ago

[deleted]

switchbak 12y ago

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.

stingraycharles 12y ago
Don't forget about websites from academia that implement certain proof-of-concepts; for some reason that commumity still keeps using applets.
- exprE 12y ago
  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).
- wbillingsley 12y ago
  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.

jsight 12y ago

The old Netscape Java Applet APIs supported dom manipulation: http://www.java2s.com/Code/JavaScript/Development/UsingJavaScriptinanApplet.htm 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.

lmm 12y ago

My guess is that Mozilla would never support it.

icebraining 12y ago
http://www-archive.mozilla.org/projects/blackwood/dom/ http://www-archive.mozilla.org/projects/blackwood/dom/

mjt0229 12y ago

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

giancarlostoro 12y ago
"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/javahistory-index-198355.html http://www.oracle.com/technetwork/java/javase/overview/javah...

zanny 12y ago

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.

electrum 12y ago
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.
- Gurkenmaster 12y ago
  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.