Filling in the Gaps
HTML started as a very simple language. By many accounts, it's still very simple. You create some text and you wrap some tags around it. The tags provide a small measure of meaning and allow user agents—aka browsers—to present the content in a meaningful way.
One Plugin to Rule Them All
One notable addition was the embed tag (and the applet and object tag after that). It's notable because it recognized that browsers could not do everything. From this sprung forth slow and cumbersome Java applets, Shockwave 3D, Real Audio streaming and more panaroma plugins than you could shake an animated trailing cursor at. Adobe Flash, née Macromedia Flash, was born in this era.
At this point, one of the largest problems for web developers was ensuring that site visitors had the necessary plugin installed. Otherwise, it required users to download it, install it, and restart their browser. Requiring this complicated process just to view your web site meant that fewer people would take the time to complete the task.
Impressively, the Flash player began to be bundled with browsers. Flash, above all else, became nearlyubiquitous with statistics showing the Flash Player being available on 99% of all Internet-enabled desktops. As a web developer, you now had technology that you could rely on almost as much as HTML but with a lot more power. At the turn of the millenium, even CSS was still gaining traction.
It's important to note that Macromedia (and Adobe) did not rest on its laurels. They continued to fill the gaps of what the browser could provide us. Between then and now they've managed to offer useful features such as cross-domain requests, local storage, binary sockets, multi-file uploads, and shared objects. On the animation front, there are 3D effects, inverse kinetics, and pixel bending. On the streaming side, there is support for multiple codecs, full-screen playback, and dynamic streaming. Flash also allows for screen, audio, and webcam capturing, as well as peer-to-peer connections.
Yet, Flash has turned into an annoyance for many consumers. Garish advertising is strewn everywhere; large, slow and confusing animated site intros are unnecessary glitz; deep-linking to content is often impossible; and normal browser features like keyboard navigation aren't available.
Flash's downfall, however, has more to do with those wielding its power—the web developers and designers who misuse it—and less to do with the technology itself.
Shifting to the Browser: is HTML5 the saviour?First, a small apology: I'm lumping a bunch of technologies under the umbrella of HTML5 for succinctness. I hope this isn't too confusing.
These days, browser developers are moving quickly to add new features; many—but certainly not all—of which compete with Flash. There is canvas, SVG, CSS-based animations, web sockets, local storage, multi-file uploads, and native video and audio.
These new features do negate some of the need to use Flash; however, I'm reluctant to think that these few features will be the death of Flash. There are simply too many use cases out there for which HTML5 does not serve. Hulu's reluctance to embrace HTML5 is very much case in point. Chat Roulette would be another. Or tinychat. Or Adobe Connect.
HTML5 just doesn't have the same breadth of features as Flash. That's not to say browsers won't get there someday. It's just not there, yet.
What of the mobile web?
The biggest question these days is, "what about the mobile web?" Or more specifically, "what about the iPhone or the iPad?" (Or Android, but it looks like they're going to have Flash soon enough.)
For the most part, I have not missed Flash. Sites have provided non-Flash alternatives or I have been able to rely on native applications to fill the void—such as with games or other applications more likely to be found in a native desktop application than on the web.
Apple certainly isn't hurting right now by pushing developers onto their native development platform. When you look at the current use cases for the mobile web, many of the features in Flash just aren't as necessary.
Yet, these devices are designed to render the web as if it was a desktop browser. Many sites are unfortunately created for the desktop with Flash as an expectation—they expect Flash to be ubiquitous for they were made in a world that predates the iPhone or the iPad. My dentist's web site is all Flash and unviewable on the iPad or iPhone. My massage therapist's web site is all Flash and unviewable on the iPad or iPhone.
Apple runs the risk that the Flash platform—combined with the right mobile device and proper access to the underlying hardware—could provide incentive for developers (and consumers) to shift their focus, time, and money to platforms other than the iPhone or iPad. Build once, run everywhere (or at least, as many places as possible) while also supporting what already exists on the web.
As web developers, we should choose the best tools and technology for the job. To do otherwise—out of ignorance or some duty to "web standards"—is a disservice to the clients and customers we serve.
Right now, HTML5 is slowly becoming a viable alternative to Flash for a greater variety of situations. However, Flash will continue to fill in the gaps for years to come because it continues to solve problems that web developers have and that can't be solved with any other client-side technology.