Chapter 7: Applets, Flash, and the Dream of Native Software

Web developers in 1996 had a problem.

The browser they were targeting — Netscape Navigator 2, Internet Explorer 3, whatever else they had to support — could render HTML, run a little JavaScript, and submit forms. That was almost all of it. No audio. No video. No animation beyond animated GIFs. No real graphics beyond static images. No drag-and-drop. No reliable cross-browser anything for the things product teams actually wanted to ship — games, banking dashboards, interactive presentations, design tools, rich media experiences.

The browser was a document viewer. The product brief said application. Some kind of bridge had to exist.

The bridge was the plugin.

For roughly fifteen years — from the mid-1990s through the late 2000s — the way the web became software was by embedding another runtime inside the browser’s page. The runtime had its own renderer, its own event model, its own programming language, its own authoring tools, its own community. The browser served the runtime a rectangular window and stayed out of its way. Inside the rectangle, a different web — richer, more capable, much more closed — ran.

Three plugins mattered. Java applets came first. Flash defined the era. Silverlight tried to extend it. All three are gone now. Their story is worth telling because the demand they were built to meet didn’t disappear — it migrated into JavaScript, where it remains today — and because the way the era ended forced the browser to grow up.

Java Applets and the Runtime That Tried to Be the Web

Java applets were the first serious attempt to put a real programming runtime inside a web page.

Sun Microsystems released Java in 1995. The language was designed by James Gosling and his team at Sun starting in 1991, originally for set-top boxes and embedded devices. By the time it shipped publicly, Sun had pivoted hard on the marketing — Java was now the language of the internet. The slogan was “write once, run anywhere.” The pitch was that a Java applet — a small program embedded in a web page via an <applet> tag — would run identically on Windows, Mac, Unix, and anything else with a Java runtime installed.

Netscape Navigator 2.0 shipped with Java support in early 1996. For a brief moment, applets looked like they’d be the way serious web applications got written. Sun and Netscape’s partnership was strong (the JavaScript name came out of the same marketing relationship, met in Chapter 4), and the major banks, brokerages, and enterprise vendors built applets for things like trading interfaces, technical visualizations, and complex configurators.

Applets didn’t take over the web. The reasons stacked up. The Java Virtual Machine was slow to start, especially on the dial-up connections most users had — clicking a page with an applet often meant waiting twenty seconds for the JVM to initialize before anything appeared. The plugin had to be installed and updated by the user, and Sun’s update story was notoriously bad. The security model — applets ran in a sandbox, but the sandbox had famous escape vulnerabilities throughout the late 1990s and 2000s — eroded user trust. And the applets themselves were difficult to integrate with the surrounding page. A Java applet couldn’t easily read or write the DOM, couldn’t share state with JavaScript without elaborate workarounds, couldn’t be styled with CSS, couldn’t be selected or copied like normal page content.

Java the language went on to become one of the most successful programming runtimes in computing — on the server, where the JVM’s performance and ecosystem profile were ideal. Java in the browser slowly faded through the 2000s, and the major browsers dropped applet support entirely between 2015 and 2017. The <applet> tag was formally removed from HTML5.

Gosling’s design wasn’t wrong. The browser, in 1996, was the wrong place for it.

Flash and Jonathan Gay

Flash’s origin story starts with one developer.

Jonathan Gay began writing a vector-drawing application for the Mac in the early 1990s while still in his teens. The app, called SmartSketch, was a serious piece of work — efficient vector rendering on the hardware of the era was hard, and Gay had a good eye for both the technical and the product side. SmartSketch shipped through a small company called FutureWave Software, where Gay was joined by Charlie Jackson and Robert Tatsumi. The vector-drawing market on Mac was thin. The company pivoted.

In 1995, FutureWave released FutureSplash Animator, a vector animation tool aimed at the web. The companion player, distributed as a browser plugin, could render the vector animations FutureSplash created — small, smooth, scalable, and orders of magnitude lighter over a dial-up connection than the equivalent rasterized GIF or video. Microsoft used FutureSplash for the original MSN website. Disney Online and the Fox News site used it too. The plugin started spreading.

In December 1996, Macromedia acquired FutureWave. The product was renamed Flash. Jonathan Gay stayed on as the architect.

What Flash became over the following decade is hard to overstate. The Flash authoring environment combined a timeline-based animation editor, a vector drawing tool, an asset library, an audio mixer, and a programming environment (ActionScript) into a single product that a designer or developer could use end-to-end. The Flash player was free, small, and installed almost everywhere — by 2005, Adobe’s measurements showed Flash installed on over 98% of internet-connected desktops, a higher penetration than any single browser at the time.

The community that built on Flash was extraordinary. Joshua Davis, Hillman Curtis, Yugo Nakamura, and the auteur generation of Flash designers produced interactive work in the late 1990s and early 2000s that has nothing comparable today — websites that were experiences, brand campaigns that were small explorable worlds, music videos that responded to the cursor, generative typography, kinetic poetry. Flash agencies (2advanced, Hi-ReS!, Group94, North Kingdom) shipped commercial work that won design awards on the strength of work the browser of the era couldn’t have produced any other way. The Flash IDE was the design tool of a generation.

The technical side mattered too. ActionScript, the language inside Flash, grew through the early 2000s into a serious object-oriented language. ActionScript 3, released in 2006 alongside Flash Player 9, was — as Chapter 5 mentioned in the ES4 context — essentially a working implementation of the ECMAScript 4 design that TC39 had been deadlocked over. Flash Player 9 also introduced a new JIT-compiling virtual machine (AVM2) that was significantly faster than the JavaScript engines of the era, and Flash applications routinely outperformed the equivalent DHTML interfaces by an order of magnitude.

Adobe acquired Macromedia in 2005 for $3.4 billion, mainly to get Flash. The acquisition consolidated the design tool industry under one company. Photoshop, Illustrator, InDesign, and now Flash, Dreamweaver, and ColdFusion all sat in the same product portfolio. Adobe was, in 2007, the company most directly betting on the future of the web being a rich-runtime, designer-authored, plugin-delivered medium.

Within three years of that acquisition, the bet had collapsed.

Silverlight and the Microsoft Side Bet

Microsoft watched Flash’s penetration with the same kind of strategic concern Netscape had once provoked. By the mid-2000s, Flash was the de facto platform for rich web content, and the platform belonged to a competitor. Microsoft’s response was Silverlight.

The first version of Silverlight shipped in 2007. The pitch was that Silverlight took the .NET Framework’s UI layer — WPF, Windows Presentation Foundation — and delivered it as a browser plugin. Developers could write applications in C# or VB.NET, target a cross-platform runtime that ran on Windows and Mac, and ship rich-media experiences without leaving the Microsoft developer toolchain. The XAML markup language gave Silverlight applications a declarative layout model that, in some ways, anticipated patterns the web would adopt later.

Silverlight was technically credible. It had real product traction — NBC used it to stream the 2008 Beijing Olympics; Netflix used it as the player for streaming video for years. Silverlight 4 added webcam access, microphone access, and printing, all years before the browser would offer equivalents natively.

But Silverlight launched into a market Microsoft had already lost. Flash’s penetration meant that any new rich-media plugin had to clear an installation hurdle Flash didn’t, on every machine in the world. Microsoft’s own customers were skeptical of locking themselves into another proprietary plugin runtime. And the timing was unfortunate — Apple’s Thoughts on Flash letter, which we’ll come to in a moment, applied to Silverlight just as much as to Flash. Apple’s iOS device population grew through the early 2010s, and Silverlight never had an answer.

Microsoft formally ended support for Silverlight in October 2021. Most people had stopped using it long before.

The Plugin Bargain

Every plugin made the same trade.

The trade was: we’ll get richer capability than the browser can offer, and in exchange we’ll stop participating in the browser.

Inside the plugin rectangle, the experience was usually superior. Animation was smooth. Typography was consistent across operating systems and browsers (Flash’s font rendering was famously better than any browser’s of the era). Media played reliably. Interaction was responsive. The plugin authors had complete control over the rendering pipeline and the input model, and they used it.

Outside the rectangle, the browser saw nothing. The page’s HTML described an empty embed. The accessibility tree had no idea what was inside it. Search engines couldn’t index it. The URL never changed when state inside the plugin changed, so users couldn’t bookmark a particular view or share a link. Copy-paste didn’t work. Browser navigation buttons did nothing. Right-click was either disabled or replaced with the plugin’s own menu. Keyboard accessibility was rare. Screen readers were essentially blind to the content.

The plugin also asked the user for trust on installation. Each plugin was a separate native runtime running with privileges the browser sandbox usually denied. Flash’s history of security vulnerabilities — particularly through the late 2000s and early 2010s — turned the plugin from a feature into a liability. The standard advice from security professionals by 2012 was uninstall Flash unless you absolutely need it. The plugin that had once been the universal layer above the browser had become the most common attack vector against it.

The plugin bargain was sustainable as long as the value of the inside-the-rectangle experience exceeded the cost of being outside the browser. As browsers slowly caught up — and as the security and performance costs of plugins kept rising — the value proposition slipped. By the late 2000s, even Flash developers were starting to ask whether the runtime they’d built their careers on was the right substrate for the work.

And then, in April 2010, Steve Jobs ended the conversation.

Thoughts on Flash

On April 29, 2010, Apple published an open letter signed by Steve Jobs titled Thoughts on Flash.

The iPhone, in 2010, was three years old. The iPad, which had launched three weeks earlier, was the year’s most-discussed product. Apple’s iOS ecosystem was the fastest-growing computing platform in history, and neither iOS device supported Flash. Adobe had been pressuring Apple — publicly, in interviews, in advertising, in internal lobbying through Adobe’s enterprise customer relationships — to add Flash support to iOS. The letter was Apple’s reply.

Jobs listed six reasons. The letter was unusually long for an Apple communication and unusually direct.

First, Flash was proprietary. Apple had spent the previous decade arguing that the web should be built on open standards — HTML, CSS, JavaScript — and Flash, controlled by a single vendor, was the opposite. Second, the “full web” claim Adobe used to defend Flash was misleading. Video on the web was, by 2010, largely available in H.264, which iOS supported natively. Third, Flash had a long and unresolved record of security vulnerabilities and reliability problems on the Mac. Fourth, Flash’s battery consumption on mobile devices — even when video played in H.264 inside Flash — was significantly worse than native playback, because Flash forced software decoding rather than the hardware acceleration mobile chips offered for H.264 directly. Fifth, Flash’s input model was built around mouse-and-keyboard interaction, and touch interfaces (rollovers, hover states, the entire interaction grammar of Flash) translated badly. Sixth — and this was the one that landed hardest in the developer community — Flash put a layer between Apple and its developers. If Apple let Flash onto iOS, Apple’s platform would advance only as fast as Adobe’s third-party toolchain allowed, and Apple’s design and engineering control over the iOS experience would be permanently diluted.

The letter concluded that Apple’s position was final.

The industry response was mixed at first. Adobe pushed back hard. The Flash community pushed back harder. Some technology critics called the letter self-serving — Apple had its own commercial reasons to keep developers on its native SDK — and others called it accurate. Both readings can be true at once.

The market settled the question. iOS device sales over the following years made the no Flash on iOS policy a fact every web product team had to design around. Mobile traffic grew. Sites that depended on Flash started getting rebuilt in HTML5. Adobe announced in November 2011 that it was discontinuing Flash Player for mobile devices and shifting Flash’s focus to PC desktops and packaged apps. The company that had bought Macromedia six years earlier to own the future of the web was now publicly retreating to the part of the web Apple’s letter hadn’t already taken.

The desktop retreat lasted another decade. Adobe announced Flash’s full end-of-life in July 2017, scheduled for December 31, 2020, and the major browser vendors coordinated the removal. On the appointed date, Adobe’s Flash runtime stopped working. A protocol-level kill switch the company had built into the player years earlier blocked it from running content. The plugin era ended on schedule.

What the Plugin Era Forced the Platform to Become

The plugins had been useful for one reason. They did things the browser couldn’t.

When the plugins left, the things they did had to land somewhere. The somewhere was the platform itself.

Video is the clearest example. Flash’s primary use case for most of its life was video playback — YouTube launched in 2005 as a Flash video site, and the entire streaming-video web ran on Flash through the late 2000s. The <video> element was added to HTML5 in 2010, with native browser support for the major codecs landing through 2011 and 2012. By the time Flash’s mobile support was dropped, YouTube and the rest of the streaming web had already migrated to HTML5 video.

Audio followed the same path. The <audio> element shipped at the same time as <video>. The Web Audio API, more ambitious, landed in 2014 and gave the platform a serious signal-processing graph that Flash’s audio engine hadn’t been able to compete with on the desktop.

Animation was harder. Flash’s vector animation was the single feature with no easy platform replacement, and CSS animations, CSS transitions, and the Web Animations API came in over the following years, each filling a piece of what Flash had provided. The HTML5 <canvas> element gave the platform a raster drawing surface; SVG (which had been in the spec since 2001 but underused) gave it a vector drawing surface. WebGL (2011) and later WebGPU gave the platform direct GPU access for the kind of work that had previously required Flash or a native runtime.

Fonts changed too. Flash had been the only reliable way to ship custom typography for years; web fonts via @font-face reached general browser support around 2010 and made custom typography part of the platform. Google Fonts launched the same year and made the distribution problem trivial.

The pattern repeats across every plugin capability. Webcam and microphone access via getUserMedia (2013). File access via the File API and later the File System Access API. Real-time communication via WebRTC. Local storage and offline-first behavior via service workers and the Cache API. Hardware access via WebUSB, WebBluetooth, WebSerial, WebMIDI. WebAssembly, in 2017, gave the platform a portable second runtime that could run code in nearly any language at near-native speed — the closest the modern web has to the kind of programming-runtime-in-the-browser that Java applets had been trying to be.

The browser’s serious application capabilities — almost all of them, taken together — are the platform absorbing the capability that plugins had once monopolized. The work the W3C, the WHATWG, and the engine teams did between 2008 and the mid-2010s was the platform growing up. The death of plugins is one of the most important reasons it had to.

The Hidden Continuity

The plugin era ended. The demand that caused it didn’t.

Users wanted experiences that felt continuous, responsive, and rich. Product teams wanted to ship software inside the browser. Designers wanted control over rendering and interaction. None of that changed when Flash went away. What changed was where the architecture lived.

The work that had previously gone into Flash and Silverlight applications didn’t disappear from the field. It migrated into JavaScript. The same problem — deliver application-grade experience inside a browser page — is now solved with single-page application frameworks instead of plugin runtimes. The same trade applies. Gain control over the experience, lose participation in the platform. A React-rendered button isn’t really a <button> you can target from outside React, in the same way a Flash button was never really an HTML element the browser could see. Both reach for an inside-the-rectangle abstraction. The rectangle has just become invisible.

The continuity is worth holding onto because the lessons of the plugin era apply directly to the framework era. The plugin won when the platform’s gap was wide and the cost of bridging it was high. The plugin lost when the platform closed the gap and the cost of the proprietary runtime began to outweigh its benefits. The same dynamic is now in slow motion across the frontend framework ecosystem. Every year, the platform absorbs another capability the framework was solving for, and every year the cost-benefit math shifts a little further toward the platform.

The book’s central claim is that the math has now tipped — that what was once a clear win for the framework is, for most applications, no longer the right trade. We’ll get there. The plugin era is the precedent that makes the claim defensible.

What Came Next

The browser couldn’t have absorbed the plugin era’s capabilities all at once. The absorption started, in fact, before the plugins ended. The first piece — the smallest, the earliest, and the one that quietly changed everything — was the ability for a page to talk to a server without reloading.

That’s the next chapter.

Exercise: Trace a Plugin Capability

Pick a capability that was once Flash-only (or applet-only, or Silverlight-only) and trace where it lives today.

Options to consider:

• Streaming video.
• Vector animation.
• Custom web fonts.
• Real-time audio processing.
• Webcam capture.
• In-page games.
• Rich text editors.
• Drag-and-drop file uploads.

For your chosen capability, answer:

1. What platform API (or APIs) now provides this capability natively?
2. When did the API ship in major browsers? (The MDN docs and caniuse.com will tell you.)
3. Is there still a JavaScript library that’s widely used for this capability? If so, what does the library provide that the platform API doesn’t — convenience, polyfilling, cross-browser consistency, or genuinely missing functionality?
4. Are there products you use today that you suspect still depend on something Flash-shaped — a third-party runtime, an embedded iframe owned by another service, a heavy JavaScript framework that effectively replaces the browser’s interaction model? What did it replace, and what did you give up to get it?

The point isn’t to grade the past. The point is to develop the same eye the rest of this book asks for: a working sense of which capabilities live in the platform now, and which still live above it.