Flash vs. Ajax

January 2009 Update

This article was orginally written in 2005, and is now quite a bit out of date. In 2008, I was asked by Web Designer Magazine to write an sequel, which they ended up using as their cover story for issue 146. Unfortunately, the new article is not available online, but copies may be purchased here.

Macromedia and the "AJAX Movement"

In early July, I attended the Flash Forward Conference in New York, and it was interesting to see how the AJAX Movement was having an impact on the mindset of Flash Developers, and of Macromedia. (Note that I feel it is more apt to describe AJAX as a movement, because it is not really a new technology, but rather a new approach for using existing technologies.) AJAX was mentioned several times in Macromedia's Keynote Address, in their Q&A session, and in a presentation on the Flash/Javascript Integration Kit.

Obviously Macromedia wants to stay on top of trends in web development, but is there also some fear on their part that AJAX techniques could supplant Flash? As a developer who works extensively Flash, and who has started to explore the possibilities with AJAX, I thought I would share some of my thoughts.

From a technological standpoint, at the moment, Flash doesn't have much to fear from the AJAX Movement. Flash is still miles ahead of DHTML in terms of what it can do on the client. And Flash is likely to stay ahead due JavaScript's dependency on old browsers. For now, the sites that end up using AJAX instead of Flash will mainly feature relatively simple UIs and functionality. Sure there will be some Big Budget AJAX apps coming out, like Google Maps, but for the most part developers will decide that the headaches of working in client-side JavaScript are not worth it. And even Google Maps is a sort of exception that proves the rule. I imagine Google has business reasons for not wanting to be reliant on Macromedia/Adobe, but one has to wonder whether their image caching and loading functionality wouldn't have been smoother, and easier for them to implement in Flash.

From a P.R. standpoint, I think Macromedia has a bit more to be worried about. Flash has always had a certain stigma about it that goes back to the backlash to against annoying animated intros. One of Flash's greatest strengths -- ease of development -- is also a weakness. Because it is so easy to build UIs and animations in Flash, it allows for the Lowest Common Denominator to rise to the top. There have been several other missteps by Macromedia, which have slowed Flash's acceptance as a serious development environment:

  • The absence (until recently) of strict programming and design standards.
  • Performance issues and buggy-ness of their pre-built components.
  • Lack of complete HTML and CSS support.
  • Text rendering issues.
The future of Flash has a lot riding on the upcoming "8 Ball" release. If Macromedia can address the issues that have held back the adoption of the Flash Platform, they can stave off the assault on their dominance by AJAX. The strategy they adopted at Flash Forward of pitching Flash as a tool that can co-exist with technologies like AJAX is probably not enough. They will also have to state more boldly, and in more detail why Flash is better than the alternatives.

Is Flash Really Better?

Audio checkmarkDynamically load audio. Support embedded flash audio. Supported only through external plug-ins (like Media Player).
Browser Integration Flash Player plug-in required. Flash is limited to a predefined rectangular area of the browser. checkmarkJavaScript natively supported by modern browsers. Simple interaction with any part of the browser.
Compatibility Issues checkmarkMinor variations between versions of Flash. Major compatibility differences between browser versions.
CSS Limited support. checkmarkFull Support (depending on browser).
Dynaic Content Generation Difficult. SWF is a pre-compiled closed format. Currently there is no language to describe SWFs. (Compare SVG, which is XML-based.) checkmarkHTML can be written out using just about any kind of Server technology. Dynamic image generation is more difficult, but is possible on some platforms (like PHP).
Programming Model checkmarkActionScript 2.0 provides robust, java-like framework. JavaScript 2.0 not yet supported by any major browser. JS 1.5 not recommended for large OOP applications.
Raster (Bitmap) Graphics checkmarkLoad static images dynamically. Support for JPG, GIF and PNG. Bitmap manipulation. Load static images dynamically.
Regular Expressions Not supported natively by AS 2.0, but open-source solutions are available. checkmarkFull support.
Server Integration checkmarkMany solutions available. Flash can communicate with ASP, PHP, ASPX and many other types of server scripts. Commercial solutions, like Flash Remoting, are also available that provide live connections to a database. Limited. Can communicate dynamically with server using IFRAME trick or XMLHttpRequest Object.
Text Text API mimics some HTML functionality. checkmarkPowerful layout capabilities.
Vector Graphics checkmarkFull Support. None.
Video checkmarkDynamically load FLV video files or playback embedded videos. Supported only through external plug-ins (like Media Player). Multiple Video Formats can be loaded.
XML checkmarkFull support. Not supported natively by JavaScript.

I think the number of checks in the Flash column give the impression that Flash is a superior solution. Certainly for many hardcore Flash developers would say that you can do anything in Flash, so you might as well do everything in Flash. But ultimately, it depends on what you are developing.

But there is one area where AJAX simply kills Flash: dynamically generated text-heavy applications. And at the moment, these dominate the web. So if you're making an email program, or an online personal organizer, or an online store, Flash doesn't make much sense. It simply doesn't give the same flexibility for parsing and displaying large amounts of text data. Anyone who's had to build a Flash app with Dynamic Text Fields knows what a headache it is. Without writing a bunch of code, there simply isn't enough flexibility available for repositioning or resizing text fields. The problem gets even worse if your app needs to be localized...

I think it's inevitable that internet apps will evolve to be more of an interactive multimedia experience. At that point -- if it's still in contention -- Flash may be poised to take over. But for now, we're still in the stone age.

Other Resources

Mark, from O'Reilly Radar writes about the Macromedia presentation at this year's Ajax conference in SF, and the ensuing debate. It sounds like he had much the same reaction to this presentation as I did to the presentation at Flash Forward: Macromedia was trying to pitch Flash as a part of AJAX, but the subtext was that AJAX was potentially a threat. Key point: "The Ajax model makes Flash (and Java, and ActiveX) unnecessary for some kinds of interface models. When I first wanted to make, say, a dynamically updating table, Java was the only choice; later, Flash was a much more pleasing choice. Now, Ajax/JavaScript offers a number of advantages over Flash: faster load time, consistent interface with the rest of the browser, a standard/free HTTP server backend, and broader development tool support." has a post the pros and cons of both platforms. He feels that the technologies complement each other, and can co-exist. This is, I think, one of the first articles that was posted on the issue.

JD on MX has only a brief post, but it spawns an interesting debate in the comments.

Mary Jo at Microsoft Watch discusses Microsoft's interest in Ajax. They could be the 500 pound gorilla that changes the shape of the playing field. IE7 comes out later this year. I predict much of the future of the Ajax Movement may turn on the success or failure of this browser.