by cfarre on 3/18/21, 9:37 AM with 70 comments
by AndrewStephens on 3/18/21, 1:58 PM
And Java was a good bedrock to build applets on - a safe language that runs everywhere in a VM.
But the implementation was terrible - let me count the ways:
* Performance was awful. Java applets performed OK (and sometimes excellently if you put the work in) once they got started but the initial start-up cost of standing the VM was just woeful. Your browser would freeze for 10-20 seconds while MBs of JVM were slowly loaded and JIT'ed. People started to avoid sites with applets for this reason. Sun never even tried to fix it, and in fact told people it was for their own good because your CPU might have changed since last time the Applet was loaded.
* The GUIs were ugly. People back then complained endlessly about the Applets looking non-standard, which was true. Big a far bigger problem was that they were just hideous. Poor default fonts (and bad font rendering), bad default colors, bad fit-and-finish. Sure you could spend time making everything look nice, but it was a huge effort. Sun did try to fix this but with limited success.
* Security. The original idea was good - perfectly sandboxed executables. But Sun fell to the pressure from people who should have known better to provide ways of calling out to native DLLs. This was a terrible idea and was the source of many, many security problems. Browsers were wise to disable applets entirely.
* Failure to respond to competition. People wanted video on the web and tried to use Java, but the Java graphics stack was pretty slow for that kind of thing. Flash came along with its bad but usable codec built in and everyone jumped ship. A missed opportunity.
If Sun had fixed these problems I might be typing this comment into a Java Applet text control with formatting and spell-checking right now.
by helsinkiandrew on 3/18/21, 12:17 PM
I think better, perhaps a few less web frameworks and paradigms atleast.
https://web.archive.org/web/20070916144913/http://wp.netscap...
by flohofwoe on 3/18/21, 12:11 PM
This news is just about the removal of some leftover applet-related APIs in the JDK, hardly news-worthy IMHO because you couldn't do anything useful with those APIs anyway for quite a while.
by EamonnMR on 3/18/21, 1:12 PM
by le-mark on 3/18/21, 12:37 PM
Obviously the entire plugin api turned out to be a “bridge to far”; security was terrible, complexity and inter-op, and useability were all atrocious. Not just applets but flash and silver light as well
by als0 on 3/18/21, 12:38 PM
by njacobs5074 on 3/18/21, 12:59 PM
They were terrible then and quite frankly I'm surprised that they lasted as long as they did.
by micro_cam on 3/18/21, 3:49 PM
by layer8 on 3/18/21, 1:13 PM
by apignotti on 3/20/21, 8:55 AM
This tool allows to safely run applets in Chrome purely in HTML5/WebAssembly/JavaScript. No plugins needed.
Over 50k users are using it, and over the years we have been shocked by how many people and businesses are dependent on this kind of legacy content.
The extension is only intended for non-commercial use, we offer business an even better/faster solution by converting Java bytecode Ahead-of-time.
Disclosure: I am CTO of Leaning Technologies, the company developing this extension and the underlying CheerpJ technology.
by recursivedoubts on 3/18/21, 1:42 PM
I live, I die, I live again
by Angostura on 3/18/21, 12:13 PM
by DonHopkins on 3/18/21, 11:51 AM
by pjmlp on 3/18/21, 5:22 PM
by anthony88 on 3/18/21, 5:11 PM
Searching for "extends JApplet" returns more than 50,000 results on github.com. SwingSet2 for example is also using the class JApplet. Removing the 6 classes will break some stuff, including all my desktop apps.
by simonh on 3/18/21, 1:17 PM
by elwell on 3/18/21, 1:51 PM
by k__ on 3/18/21, 12:05 PM