The internet as we see it today is still a fairly recent phenomenon. In 2016, even the most pedestrian, phone book-looking website aspires to be something more than merely an "entry" within the grand information catalog of the web. It aspires to be an application. A program. An interactive experience. It wasn't always like this.
Practically speaking, what we see today comes mostly thanks to the introduction of scripting languages to an otherwise (relatively) static web. Whereas HTML, as a markup language, tells a web browser how to make a website look a certain way via a limited set of abstract building materials, it doesn't really have the capabilities for telling it how to make a website do things. That's just what it is to be a markup language.
This is a recent capability/movement, but the idea of an interactive web page is decades old. One of the concept's defining moments came in 1995 with the introduction of the Java programming language, and, with it, the Java Applet. This is a small program-like unit (an app, really) that can be embedded in a web page, offering capabilities for any number of program-like things: basic interactivity (e.g. rollover effects), small games, visualizations, and other realizations made possible by the Java programming language. If you can remember the web of 10 years ago, you can almost certainly remember being nagged by some webpage to update your Java installation to run an Applet.
Java's corporate parent Oracle announced this week that it's finally killing the Applet. It makes sense. There's no longer any real need for the technology, and, as such, browsers have stopped supporting them. It'd be a pretty goofy thing to continue dedicating resources to. For the better part of a decade, however, the Applet was the internet's outlet for creative interactivity.
The heart and soul of the Java applet is a clever fudge. The browsers of yore weren't capable of interpreting programming languages, but browsers are also themselves just programs executing with the same contexts as other programs on a computer, including the Java Virtual Machine (JVM).
So, if a user has both a browser running and a JVM running, maybe the two could join forces. That's the basic idea of an Applet. Applet code is stored on a server with the rest of its parent web page, but when it gets to an actual browser, a separate process from the browser is created on the user's machine. Behind the scenes, the new Applet process runs on the JVM like any other Java program while the browser renders the rest of the webpage as usual.
The success of Java itself would be in slow, deliberate entrenchment in the oatmeal world of enterprise software.
In 1995, this was pretty exciting stuff. The newborn Java language, the creation of Sun Microsystems, was immediately tasked with taking on the web. 1997 saw the release of the HotJava browser, the first to accommodate Java Applets. It was to be Sun's big demonstration of the technology and, with it, the potential of an interactive web.
"HotJava Browser 1.0 is a powerful tool that allows developers to quickly create their own style in the user interface, or create network applications that use URLs and HTTP to transport and locate information," a Sun press release announced. "For example, HotJava Browser can be used to develop customized information kiosks that businesses could use to provide information to their customers. The kiosks would display HTML-based pages and customers would use HotJava Browser to browse the information. The kiosks' graphical user interface would be completely tailored to reflect the branding of the business. HotJava Browser is completely customizable and lets any business create a browser-based user environment that is in its own image."
A 1999 white-paper in the industry journal HP Professional extolled the virtues of the new Java way: "Software companies spend a fortune building separate code for Windows NT, Windows 3.1, Linux, MacOS, Solaris, AIX, etc. This is a major headache for every IT shop. Java has achieved the greatest success in letting developers write Java code once for all platforms. When applications are written in Java, the resulting bytecode will run identically on any JVM."
"Java is being widely used from developing browser applets to serious enterprise applications," the paper continued. "It is being used to reengineer global reservation systems, to speed ERP implementation and to improve call centers. What started as an improved programming language is now an architecture that is reshaping our enterprises and the World Wide Web."
As Java dug in in the early 00s, Applets thrived. Put simply, they could do cool things.
A quick survey of academic and industry journals from 2000 to 2005 finds Applets powering early camera-phones and covert CCTV set-ups, visualizing protein sequences, processing and analyzing shipping data, enabling early online learning tools and "3d-enabled cyber workspaces," and more. This is all in addition to what Applets could do within the context of everyday web interaction. It's an easy technology to hate on in 2016—inelegant, awkward, slow—but Applets spent a cool decade or more predicting the internet of applications we now have before us.
So, what happened? When's the last time a Java logo nagged you to install or probably reinstall Java to run some widget? It's probably been a while.
The term for what JS does is "client-side scripting," which you may already be familiar with. A script within the context of a web page can be taken to mean just some instructions that manipulate the HTML of a page in a prescribed way, perhaps in response to a user's input, like a click or a mouse movement.
The resulting effect to the ecosystem is that Java applets are still present in the platform, and are a major contributor to security problems.
And it also one ups the Java Applet. No more JVM, just the whirr of optimized machine code running on hardware.
In Java: The Legend, Benjamin Evans summarizes the current state of the Java Applet as such:
Applets are a technology that are very much of their time, and they have not aged well. The technology proved to be very difficult to evolve, and so applets have not been considered to be a modern development platform for many years now. However, they doggedly persist due to some large early adopters being very resistant to change. The resulting effect to the ecosystem is that Java applets are still present in the platform, and are a major contributor to security problems.
That was written before the official demise of the Applet in 2015. The technology was already practically deprecated, even if it persists in legacy systems. Those systems will have until 2017 to migrate Applets to other platforms and frameworks, though they should probably get on that, like, yesterday. The impetus for Java dumping the Applet is chiefly that modern browsers had already dumped it or were in the process of dumping it along with other plug-in based technologies, such as Flash and Silverlight.
This one is from Oracle, the current corporate parent of Java:
Java's rapid rise to fame 20 years ago began with a tumbling duke applet running in the HotJava browser, long before Microsoft Internet Explorer, Mozilla Firefox or Google Chrome were released. Applets allowed richer development functionality through a browser plugin at a time when browser capabilities were very limited, and provided centralized distribution of applications without requiring users to install or update applications locally. The Netscape Navigator browser went on to popularize a standards based plug-in model with the Netscape Plugin API (NPAPI), which was in turn adopted by many other browsers, allowing plugins to extend the capabilities of browsers to provide cross-platform and cross-browser functionality.
As Java evolved to become one of the leading mainstream development platforms, so did the applet's hosts – the web browsers. The rise of web usage on mobile device browsers, typically without support for plugins, increasingly led browser makers to want to restrict and remove standards based plugin support from their products, as they tried to unify the set of features available across desktop and mobile versions.
To understand the legacy of the Applet, a good place to look is the massively popular Processing programming language, which has become the language of choice for creative coding—that is, a syntax for art. Processing is really just a Java wrapper language, and the decision to use Java instead of some other language like C++ traces back to the Applet.
"In one sense, Processing arose as a response to practical problems," writes John Maeda, an artist and computer scientist that advised the duo behind the Processing language at MIT, in a history of the language. "When Java first came out, it offered minimal support for sophisticated graphics processing. Drawing a line and stuff like that was possible, of course. But it couldn't do transparency or 3D, and you were almost guaranteed to see something different on a Windows computer and a Mac; it was incredibly cumbersome to do anything that was both sophisticated and cross-platform."
"So [Ben] Fry," he continues, "who grew up hacking low-level graphics code as a kind of hobby, built from scratch a rendering engine that could make a graphically rendered scene appear the same in a Windows or a Mac environment. It was not just any renderer–it borrowed the best elements of Postscript, OpenGL, and ideas cultivated at the MIT Media Lab in the late Muriel Cooper's Visible Language Workshop."