Summary of possible reasons why Java applets failed to catch on, dispite heavy initial momentum:
- Microsoft's luckluster browser support
- Didn't have a native OS GUI look-and-feel
- Were difficult to partition such that they often required long load times
- Optional "click-me" loading & starting should be the default for embedded applets (arguably for any bulky content, not just applets).
That's what I do with my WebBrowser
s: I disable Java. Why? Because every time I get the little message that says "Starting Java" I know that I'm going to have to sit a wait for a long time while the JavaVirtualMachine
too because those little pop-up advertising boxes are just soooo damn annoying. Anyone else do this? -- AndyPierce
No (I actually like seeing what some of the people who write applets are up to), but I edit /etc/hosts to have any domain names from which ads are served redirected to localhost, where my lil' server has a nice blank image ready to answer any request with. TechnicalDisobedience?
, man. ;)
First thing I do is disable Java.
I have automatic download of .gif files disabled as well.
Yeah? Well, I only use telnet, and only on an actual VT100 terminal. None of this GUI crap for me. And I smoke unfiltered Camels and drive a stick and pump my own water from a well I dug myself with my bare hands. ...GIF files my achin' butt.
Me, I look at all my GIF files through a text editor...
Heck, I use morse code.
Silly jokes notwithstanding, I'm with Andy. I have seen perhaps five examples of client-side Java that I thought were useful or genuinely cool. Comparing that to the literally hundreds of worthless JavaApplets out there, the odds of finding a good applet are too slim to go through the hassle.
Of course, this is less of a problem today than it used to be ... Now all the flashy resource-wasting goes to MacromediaFlash instead of Java. Which proves either that Flash will replace Java client-side, or that client-side Java really was worthless all along. Can't decide which. -- FrancisHwang
Flash has replaced client-side java for fluff. Java remains useful for things like in-page InternetRelayChat
assuming that an in-page IRC client was a good idea...
The difference is that Flash-style fluff is used in a manner that makes content accessibility difficult. (Less so with Flash than with applets, but the complaint is still valid.) An in-page IRC client is a service, by contrast -- it is
I often disable Java as well. But I'm sure there are UsefulJavaApplets
The problem with Java is that it isn't particularly good at interacting with a webpage, so it's not very easy find a good JavaApplet
. It's just so inappropriate. Compare your favourite text editor's macro language, like elisp (EmacsLisp
). elisp happens to be good at manipulating emacs (EmacsEditor
for some definition of useful. But Java just doesn't belong on a webpage. Similarly, it doesn't belong on handhelds because it's a bloated hunk of unportable crap. People now claim it belongs on the server, but that's another question. shrug
The biggest problem with JavaApplet
s is that they seem difficult to modularize so that one gets JustInTime
client-side loading. Usually bunches of classes have to be loaded on the client before anything happens, perhaps the entire app. It would be nice if it only loaded what was used. A form-based approach, for example, would only have to load forms that the user actually goes to instead of all potential
Perhaps Java applets can
be partitioned such a way, I don't know, but almost no writer seems to do it. They are all a big ball of all-or-nothing. Some have tried to split apps into multiple applets, but the communication and caching between them was not very good, they reported.
: Rename topic to WhyAppletsFailed?
, which is more diplomatic.
: Diplomacy without advesary is vacuous. JavaAppletsSuck