The Demise of Flash

I've seen the meme that "Flash is dead" made increasingly often lately (e.g. here), and as someone who works with Flash on a regular basis, I wanted to address it a bit.

Flash is (should be) enjoying a much reduced presence on the web in future: technologies are coming into general use that dramatically reduce the places where you'd need to use it.

The Flash Site

Fully Flash sites, featuring piles of animations and visual effects were one of the first cases of Flash on the web (I've done a few). They're especially popular with ad agencies and design companies that don't know the web very well (or haven't updated their site in a while). For this sort of stuff, we can really stop using Flash.

The effects that are possible with Flash that'd you'd want to use (moving/scrolling elements, sliders, fading in and out, etc.) are easy to do with jQuery/jQuery UI or prototype/scriptaculous or a half a dozen other JavaScript libraries. The sorts of things that aren't feasible with this arrangement are generally things that shouldn't be done or are just showing off (the latter of which is fine if you're a Flash design agency, as 2advanced is). For almost anything that resembles a website, a standard HTML/CSS/JS stack should really be able to suffice.

Why not make a Flash site anyway? They're slow to load, slow to run, hard to make properly accessible, bad for search engines, and just generally a pain. Also, they're typically bastions of non-standard interfaces. After all, if you wanted a standard website interface, why would you be using Flash in the first place?

The Web Application

There are a number of (usually graphics-intensive) web applications that run based on Flash, like the Aviary suite, or Adobe's Flex framework is really aimed at building web applications, though it has broader uses as well.

This is an area where Flash is losing ground. JavaScript-based web applications are becoming more and more capable, but for graphics manipulation, support in JavaScript really doesn't exist yet. (The outlines do, via <canvas> and SVG support, but until IE picks up one or both of these, it's still not there yet. More on this later.)

Flex does have another advantage, which is Adobe's AIR environment, which lets Flex apps (like TweetDeck) serve equally well on the desktop or in the browser. There are alternatives to this (most notably, the Cappuccino framework and its Atlas IDE, and some mobile platforms (Palm's WebOS and the iPhone) allow web apps to run as or emulate native functionality. But for the moment, AIR is the only such environment that's cross-platform across desktops and on the web (though, notably, not on the iPhone).


It's possible to do some limited games using only HTML/CSS/JS, but in general, graphics-rich gaming is going to be the province of Flash for the foreseeable future. It's technically possible to do some serious stuff with Canvas—but the amazingly lousy support IE has for it hampers performance far too much for serious games. And, frankly, the Flash games community is so large that I'd expect it to be one of the last communities to adopt an alternative approach.

Interactive Graphics

Much like with games, lack of Canvas or SVG support in IE limits what's possible with interactive graphics (maps, charts, tables, etc.). A rich graph like this one would be nearly impossible to make work, and work cross-browser, without Flash. Like graphical web applications and games, this is waiting for Canvas and SVG support to become richer and more widespread.

Font replacement

sIFR is probably the most common font-replacement technique on the web now. There are JavaScript alternatives like Cufon, which relies on SVG (sensing a trend?) or FLIR, but Cufon isn't cross-browser and FLIR generates non-selectable text (images).

There's also the @font-face CSS system, which is facilitated by services like Typekit, and unlike sIFR (or Cufon or FLIR), its feasible (even encouraged) to use this on body text. However, there are licensing issues, font format issues, browser adoption issues, FOUC issues, and more. Take a look at Nice Web Type for some more information.


Flash runs most of the video on the web, including every major video sharing site (YouTube, Vimeo, Viddler, etc.), not to mention Hulu. HTML5 included this nifty <video> element that was supposed to make Flash video on the web a thing of the past. Unfortunately, the whole thing got mired in the codec wars, and Microsoft has yet to give any hints of whether they'll support H.264, as Apple and Google advocate, or Ogg Theora, as Mozilla and Opera want—or if they'll stalk off in a huff and tell everyone to use Silverlight.

In the meantime, supported video codecs will be officially unresolved in the final definition of HTML5, and so long as Firefox can't adopt H.264 (its patents don't expire for another 15 years) and open-source alternatives remain prohibitively poor*, we're stuck. Which is to say: Flash video is here to stay for the foreseeable future.

So what have we got?

For web design, Flash is toast. We shouldn't be seeing fully Flash sites in almost any cases. For graphics-rich content—some applications, most games, many interactive graphics—Flash is still clearly the way to go. sIFR, though a royal pain to use, is also still often the best option for font replacement (more fonts can be licensed for it, more browsers support it). And for video, there's not even a probable replacement in the works. Even in cases where a replacement exists, cross-browser issues are going to plague it for years to come, whereas Flash comparatively just works right everywhere (assuming you can get it to work).

Regrettable as it is, Flash isn't going away.

*from the Ars Technica article: "If [YouTube] were to switch to Theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the internet," according to a manager at Google. If true, that's prohibitive.