Java Applets Suck
Java Applets SuckSummary of possible reasons why Java applets failed to catch on, dispite heavy initial momentum:
That's what I do with my WebBrowsers: 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 invokes itself in order to run whatever cute application I wasn't interested in seeing anyway. As a side bonus, when I quit the browser I have to sit around and wait for Java to tidy itself up before it dies. It's just not worth it. Sometimes I disable JavaScript 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 clients.
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 the content.
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), so you can found loads of useful elisp. You can similarly find useful JavaScript 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 JavaApplets 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 forms.
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.
EditHint: Rename topic to WhyAppletsFailed?, which is more diplomatic. EditHint: Diplomacy without advesary is vacuous. JavaAppletsSuck. LiveWithIt?. (LackOfDiplomacySucks? :-)
EditText of this page
(last edited May 17, 2007)
or FindPage with title or text search