Why Java Applets Shone and Faded: Lessons from a 90s Web Revolution

Java Applet Overview

In 1995 James Gosling demonstrated a 3D molecular model in a web browser using a Java Applet. The <applet> HTML tag instructed the browser to download compiled Java class files and run them inside a sandboxed Java plug‑in.

<applet codebase="." code="Hello.class" width="460" height="160"></applet>

When the browser encounters the tag it loads the specified .class files via the Java plug‑in, creates a separate JVM instance, and executes the code with restricted permissions (file system, network, etc.).

Key technical limitations

Outdated GUI – Applets used AWT/Swing, which produced interfaces that looked dated compared with native desktop applications.

Performance constraints – Early PCs (1990s) had limited CPU and memory; early Java runtimes lacked JIT compilation, resulting in slow execution, especially inside a browser plug‑in.

Network overhead – Typical dial‑up speeds (~56 kbps) made downloading even modest .class files take many seconds; required specific JRE versions to be fetched, further increasing latency.

Security and vendor lock‑in – The sandbox model was controlled solely by Sun/Oracle, limiting openness and raising security concerns.

Deprecation

Because of these drawbacks browsers removed support for the java.applet package. Starting with JDK 26 the package was deleted, and modern browsers no longer include a Java plug‑in.

Successor: WebAssembly

WebAssembly (Wasm) defines a binary instruction format that can be generated from languages such as C, C++, Rust, and Java. Wasm modules are downloaded like any other resource and executed by the browser’s built‑in engine, eliminating the need for external plug‑ins while preserving the original goal of running compiled code safely in the browser.