I could write a book on the missteps that killed applets. The idea of applets was great and very forward-thinking - self-contained pieces of functionality to provide UI that HTML couldn't. Web Components are a similar idea 20 years later.
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.
I don't think security was approached correctly at all, even from the beginning.
The problem is they ran in an environment where only "dangerous" APIs were blacklisted but otherwise you had pretty much full access to all JVM features and capabilities. A blacklist approach does not work for security. It only takes one hole. With an expansive API like the JDK, that ended up being a horrible game of whack-a-mole to try and patch holes as they come up.
Applet security would have been much better done as a completely separate runtime from the standard JDK with only the APIs that make sense for applets. That, however, is a lot harder to pull off (at least initially).
Agree about everything else, though. Applets were in the right place at the right time but poorly executed. So poorly that techs like flash ate their lunch. (And I don't believe flash was particularly well executed, just better than Applets).
If only the conversations between Sun and Netscape had gone a little differently back in the day, and we'd had a single language/system in the browser – 'java' integrated with HTML and decent JVM sandbox shipped in every browser. Things would have looked very different today.
I think better, perhaps a few less web frameworks and paradigms atleast.
>If only the conversations between Sun and Netscape had gone a little differently back in the day, and we'd had a single language/system in the browser
Brendan Eich said there were discussions with Sun (e.g. Bill Joy) and Marc Andreessen and all agreed[1] there should deliberately be 2 languages instead of 1 in the Netscape browser:
(1) an "easier/simpler" scripting type of language LiveScript aka Javascript
(2) a "professional" compiled type of language like Java for more complex applications
So, it wasn't an accident, or case of NIH Not Invented Here, or corporate bickering.
What they didn't foresee in 1994 is that the non-professional Javascript would end up adding more (pro) features that it enabled it to eliminate the need for Java Applets.
The biggest problem with Java was that it sucked. Java took too long (and too much RAM) to initialize, was too slow to add features, and had too poor developer tools to become the runtime for the web.
Instead Flash took that spot! Only because Flash eventually also ended up sucking too bad (on mobile) did we get the Javascript revolution.
If Java sucked less and developed at the same pace as Flash did, but was open enough that the browsers could implement their own <applet> runtime replacements (for instance if Java was more important for the web than for the server, Google may have bought Sun instead of Oracle), we would probably live in a very different world today.
>Only because Flash eventually also ended up sucking too bad (on mobile) did we get the Javascript revolution.
If "mobile" means the Apple iPhone release in 2007 not supporting Flash, I disagree.
The Javascript revolution for serious apps was arguably started by ~2000 Microsoft's XMLHttpRequest() api which other other browsers like Netscape immediately copied. This started the AJAX dynamic web page era ~7 years before 2007. When retrieving new data for a webpage is no longer tied to a user refreshing with F5 key or a HTML form submit() button, it enables a more desktop-like paradigm of apps such as:
- 2000 MS Outlook for Web
- 2004 Google Maps, Google GMail
- 2005/2006 Google Docs & Google Sheets (acquisitions)
These were the type of groundbreaking Javascript apps that convinced many that the often-dismissed "toy language" was viable for complex work. The later innovations such as 2009 Node.js runtime on the server side and 2008 V8 performance optimized js engine in Chrome just further cemented Javascript's domination. The Javascript mindshare momentum was already unstoppable long before Steve Job's declared that Flash sucked.
flash was adressing another side of that coin, presentation/appeal/multimedia
ajax was big but at best it meant slightly more dynamic business application, flash made only videos and freeform graphics ubiquitous (for better or worse)
Multimedia died in late 90s. No one no longer wanted to read text in tiny unscrollable unsearchable rectangle with "real book-like" page flipping animation and colorful textured background. All these things looked garish and vulgar long before "web 2.0" and mass javascriptization.
Flash was only good for games, short animated movies and tolerable for videos and audio (before web video standards).
From what I remember. IE was the dominant browser. And they refused to upgrade their JVM. I believe it stayed 1.1 for years. So basically, MS knee caped Java.
It really was Marc, Bill, Rick Schell (VP Eng at Netscape) and me. No one else involved, and Rick was least involved but he came through at key junctures to preserve JS and also to keep a "third language" (a PHP like server-side thing from the LiveWire team) from being created on the sly/on the cheap.
In many cases user or players (video games) involvement is really tough to predict. IMO, the best people for that are game-designers and their method is to play test. In other words, we can't predict how users react to particular technologies.
The two programming languages could still have been orthogonal to the presentation layer. Java with Dom or Livescript with Dom. I guess it was impossible to foresee dom/css being sufficient for complex applications though.
>April 3, 1998: Will Javagator be reborn as Jazilla? [...]
>Fortunately, Netscape's Java Rhino JavaScript engine managed to make it out into the world: [...]
>Javascript Jabber: 124 JSJ The Origin of Javascript with Brendan Eich [...]
>Brendan Eich:
>And Netscape had acquired a company called Digital Styles that was known for rendering engines of some kind. And they started doing a next-generation engine in ’97 I think based on Java. And they thought, Netscape’s doing the Javagator, Netscape and Sun are going to kill Windows, Java’s going to be the future on the client side. Let’s build a Java engine. When Java got the plug pulled from it in late ’97, when the Electrical Fire JVM that Waldemar Horwat was building at Netscape got cancelled, when Sun went away because Netscape was basically going out of business slowly, the team that was doing this Java engine, this Java web engine, rendering engine called Raptor said, “Oh, we better rewrite it in,” maybe it was called Xena, I forget. They said, “We better rewrite it in C++.” And then they said, “Let’s sell it to Mozilla.”
>[...] MSFT was even afraid of AOL, Oracle, and others teaming up to offer a home appliance (eg. a net PC) at low prices and undercutting the PC industry. Of course, those partnerships and alliances never did work out. Sun and Netscape hated each other, for example. [...]
Ain't that the truth! The bitter irony is that a bunch of the Sun-hating Netscape programmers went over to AOL after the acquisition, just to be mis-managed into the ground by a bunch of "Alliance" managers from Sun.
>Case told the Netscape workers that after the merger is completed next spring, stock options will remain valuable, their sabbatical program will remain in place, and their corporate culture will remain intact.
>"Maybe you joined the company because it was a cool company," he said. "We are not changing any of that. We want to run this as an independent culture."
>Netscape cancelled a project to develop a Java version of Netscape Navigator with Sun Microsystems Inc. because Netscape couldn't afford it, according to Kannegaard. Kannegaard's claims are at odds with the story Netscape told publicly about the reason it killed its so-called Javagator product. "It was explained to me that after Microsoft in their [Netscape's] words undercut their business, they could not afford to continue the project, so they had to reduce their engineering resources and cancel this project," Kannegaard said.
>That is not the story Netscape told the general public. According to a story in ZD Net's sister publication, PCWeek published Feb. 26, 1998, Netscape said it was pulling back on Javagator in hopes of getting help from Network Computer manufacturers such as Sun and Oracle Corp.
>After the layoffs, iPlanet will largely be a Sun satellite. As of last July, only one-third of iPlanet's approximately 3,000 employees were from AOL, Sun Chief Financial Officer Mike Lehman said. Lehman has further said that Sun largely owns iPlanet's intellectual property.
Rose tinted glasses I suspect. Don’t forget in the 90s the average desktop wasn’t powerful enough to run Java at a decent speed and the JVM startup time was in the tens of seconds.
It’s never told as such, but having been around at the time I suspect JS came to be largely from Java’s lackluster performance.
I’d go so far as to say if the web had depended on client side Java it may never have taken off.
It also had to do with Java's availability being hit or miss - a lot of times, you'd have to jump through some hoops to enable Java support, whereas Javascript always worked.
JS before V8 was painfully slow. But yeah the startup times of Applets were an issue on a whole another level. I'm glad we have WASM now so maybe powerful and clean languages for coding web UI will be in our future.
The JVM or the libraries? - I guess both are large.
But the advantage of browsers shipping with all or parts of a standard Java library would be that most webapps wouldn't need to ship a huge number of node dependencies, fewer leftpad Node debarcles and reinvention of the wheel.
I remember in 1996 whenever you hit a page with a Java applet, the initial JVM initialization froze my browser for 30 seconds while the hard disk thrashed away. Maybe out home machine didn't have enough RAM.
Applets were a powerful tool in 1997, I was doing stuff you need to use webrtc for with just applets back then, even used applets for my MFA, unfortunately since I was doing this in art school employers refused to hire me to do java for pay, things were very skewed back then when everybody demanded that bscs.
Please read https://news.ycombinator.com/item?id=1894374. Java was not in embeddable shape in 1995, there was no way it could be the one true language. It was also a pain to use, frankly. MS would have romped all over it with VBScript.
Confusing title, because Java Applets are already dead since around 2015 when Google and Microsoft removed NPAPI support from their browsers (and Firefox followed in 2018).
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.
My first thought when I read the title was that it will be 20 years before even 80% of Java users upgrade to the version of Java that doesn't support Applets.
If I had to guess I'd say your project is either a control panel for some sort of network-attached device (e.g. a NAS or UPS) or else the configuration manager for a server blade chassis. I could paper a wall with the number of IA waivers I've had to get to keep some ancient browser/java/flash version around so I could access some config thingy to hardware we bought years ago...
Before flash came to dominate browser games, there where Applets. The tooling wasn't there in the same way it was for flash, so it wasn't the same explosion of creativity. But there was some fun stuff out there, arcade clones, etc. I did a writeup of how to go and relive some of that fun: http://blog.eamonnmr.com/2020/03/playing-a-90s-web-game-in-t...
The most fun I had with applets was the java4k gamescompetition that for a few years required the entries to be applets. At the time I thought there was something really cool about deploying a game on a static html page that anyone could click on and play. Of course actually getting the java plugin installed was usually the challenge.
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
Depends on the complexity of the applet. The Javascript security model is a bit different from the Java model, so some complicated applets won't work right.
A lot of 1990s web technology is only comprehensible through the lens of absolutely enormous amounts of money being poured into it because some people saw a chance to displace Microsoft by getting a runtime onto everyone's system that didn't depend on them. This money ran way ahead of engineering's understanding of how to build a system like this, so we got stuck with some deeply suboptimal decisions because some suits needed this tech now now now if not yesterday to compete with Microsoft.
Even Javascript itself is the product of that, because Brendan Eich was given like a week to produce the counterproposal to having Java as the main runtime in the browser. Certainly no matter how you slice it after decades of experience we were going to have some opinions about how to fix it, but how many of the JS "WTF"s could have been avoided if he'd been given so much as, let's say, two weeks?
Reading anything about Netscape in those days shows that A: the engineers were smart and experienced and worked miracles with what they were given (IMHO, far beyond anything the suits had a right to expect from them) but B: ultimately they simply didn't have anywhere near enough time to do the sort of work the suits were demanding. Ye olde "can't make a baby with 9 women in one month" struck them hard... no matter how many people they could throw at the problem, you just can't bring up an entire tech stack like that in an all-fired tearing hurry and expect good business results.
I'm deeply unconvinced that if Java itself had not been lifted by this tide that it would be the #1 programming language today. It certainly has some neat advantages over C++, but it has a lot of massive deficiencies too, and I can assure you that some of them are so obvious that I could see them in the language as a computer science senior with already a couple languages under my belt in 1999. The amount of tooling around Java to overcome those deficiencies remains quite staggering.
I find it amusing that ultimately, Sun was correct. The browser could be used to lever Microsoft out of its desktop dominance. Just not without about another 15-20 years of development. And when that development finally occurred... it was ultimately Microsoft that produced the web-based office suite anyhow.... yup, desktop Office dominance successfully displaced! By Microsoft.
What killed of Microsoft's near hegemony on all personal computing was them losing the mobile wars. Until then they had a total dominance over the browser. IIRC IE6 had more than 90% market share some of which competed with older versions of IE.
Everyone should be cheering on this stumble because we came within inches of MSInternet that worked on IE only powered by the ActiveX controls or whatever other proprietary bullshit Redmond wanted to foist on us.
Oh, yes, I agree. I thought about that but thought it would just overcomplicate my point. I just think it is... ironic? humorous?... that ultimately the whole big rush to displace Microsoft was indeed based on correct logic... it's just that I can't imagine how it could have ever worked out for them by, let's say, 2005. The tech stack simply wasn't there and I can't see what would have changed that fact, even in hindsight. The web has nearly killed the Microsoft office suite... with Microsoft's web office suite.
Ironically they won the tablet wars due to Google not being able to move Android beyond phone apps in bigger screens.
Outside iPads, almost everyone doing serious work on the go is using Windows tablets in some form, either proper tablets, or hybrid laptops with turnable screens or detachable keyboards.
Java Web Start/JNLP/IcedTea is a good replacement if you don’t need direct integration of a Java UI into a web page. Integration with web applications is still possible by having the Java application run a service on localhost that the web app can communicate with. That can be used for web apps that require access to OS services that browsers don’t provide but the JVM does.
There is a whole heap of applets for educational content, e.g. interactive simulations of experiments and such. Those are still useful but unlikely to be ported to Javascript, similar to lots of Flash content.
If the Java VM weren't as botched and insecure as it is, applets would still be with us, at least as an important part of internet history and retained tools and knowledge.
The JVM itself shipped with a ton of vulnerabilities, e.g. in vendored ancient versions of libjpeg and similar stuff. Those didn't only affect applets but all Java client and server side applications that presented e.g. image processing as an attack surface.
Also, vendoring the JVM itself by virtually all java applications lead to those vulnerabilities being exploitable for ages, even after they were publicised and fixed in the latest version. In that regard, the JVMs were usually in worse shape than the browsers' applet interface which was updated far more regularly.
No, other than the bytecode validation bugs, IIRC the security issues were mostly in the JVM's sandbox. It used a blacklist model in which each "dangerous" operation was supposed to call the security manager, which would check if the calling code had permission to do the operation; but there were often holes in these checks, usually chaining several innocent operations and making use of Java's powerful reflection, which allowed an applet to trick "trusted" code in the JVM into doing the supposedly forbidden operations.
You have a good point: Ken Perlin still has a whole lot of great educational Java applets on his page, which he's been developing and using educationally since the very early days of Java.
The word sad doesn't appear on the linked article right now, so maybe it got changed or it is an editorilized submission title? Maybe it was inteded as sarcastic? It's hard to tell.
Even if Applets are no longer used in the browser, they are a good candidate for a plugin system. That's what I did in some of my software: just provide a file or url and you have another software running in my software.
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.
What's the status of J2ME? It still seems to exist although I can't find any evidence of it being updated in the last 10 years. When it came out, I was expecting it or a close derivative to end up being pushed as a browser technology as well. It seems like it would have been much better suited to it than Applets ever were.
I have fond memories creating Java applets in high school; mostly games, physics sims... and later, a multi-calendar Google Calendar interface (one of the first times I got paid to write code).
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.