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.
Videos by VICE
Doing things would be the domain of scripting languages, like JavaScript and PHP, and the modern servers and browsers capable of interpreting them. Now, websites naturally become programs unto themselves.
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.
HotJava
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).
The JVM is what enables the Java language, functioning as an intermediate layer between the low-level guts of a computer and its high-level programming. That is, a program in Java runs within the confines of another program, the JVM, which emulates actual computer architecture. This is somewhat analogous to how JavaScript, which is mostly unrelated to Java beyond the name, conventionally runs within a web browser.
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.”
Applet by Lookang/Fu-Kwun Hwang. Image: Wikimedia
Hype ensued. With that hype came JavaScript, a language whipped up by Netscape engineer Brendan Eich in 10 days in 1995 to be featured in the forthcoming Navigator 2.0. The JavaScript name usually taken to be a quick cash-in on the Java buzz of the time. JavaScript would eventually crush the Java Applet, but you probably wouldn’t know it at the time. JavaScript promised much of the same web functionality as Java, but Netscape (and Microsoft) were busily implementing their own JVMs, thus enabling Java Applets to run on non-Sun mainstream browsers.
Flashiness would wind up being JavaScript’s thing. The success of Java itself would be in slow, deliberate entrenchment in the oatmeal world of enterprise software, e.g. the long-lasting collections of programs that together serve the needs of whole organizations. The Java language promised “write once, run anywhere” functionality—that is, code written for the JVM would run the same regardless of the underlying machine or operating system. Programs written for the JVM, which include several other non-Java languages that run within the same virtual environment, are said to be platform-independent.
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.”
JavaScript returns
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.
For one thing, JavaScript came back at its namesake hard.
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.
So, there is server-side scripting, which is what PHP does, and there is client-side scripting, which is what JavaScript does. The prior means that a script is running on server somewhere, and is likely meant to interact with a database in some way, while the latter means the script is running on your computer via a browser. When we usually think of “cool stuff” happening on a web page, we’re usually thinking of stuff happening on the client side in terms of some real-time interaction.
JavaScript is able to do its thing because modern browsers are built with JavaScript engines. These engines behave in a way similar to the JVM described above, but, rather than mimic a full-on computer architecture, the engine’s job is to use the instructions provided in a script to change some HTML in interesting and useful ways.
JavaScript didn’t immediately sink the Java Applet, despite web browsers now being able to do cool stuff without having to farm it out to the JVM. This is because for many years the JVM still offered performance advantages. It makes sense: the Applet has access to the full resources of a simulated computer, while, until recently, JavaScript code was left to dork around with HTML via the relatively limited capabilities of a browser. One is essentially a program, while the other fakes being a program.
“Sand Traveler” generative art Applet. Image: J Tarbell
V8
Everything changed in 2011. Thank Google for this one. Whereas JavaScript had conventionally been run within the confines of a browser, the release of Google’s V8 JavaScript engine meant that JS code would now be compiled by Chrome and then run on the user’s actual machine. In Google’s words: “V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter.” That’s pretty cool.
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.”
In a sense then, the Applet is thriving. What it originally intended to do—make web pages into living and breathing computer programs—has reached its realization via JavaScript, while the Applet’s creative aspirations live on through Processing. Some two decades after its introduction, the web has indeed become a realm of web pages doing every imaginable cool thing.
