The Ajax/Flash continuum

Whenever I’m talking or writing about Ajax I’m at pains to point out one of the biggest issues that I see with a lot of big Ajax apps out there. The problem in a lot of cases is that they are even using Ajax at all.

Let me explain…

The whole reason for using standards like (X)HTML, CSS and JavaScript, in my opinion, is that they allow you to build sites using progressive enhancement. Fancy browsers get the fancy experience; simple browsers get the simple experience. Ajax can fit quite nicely into this mix. By adding some unobtrusive Ajax enhancements, you can enrich the user experience without sacrificing universal access to your content.

But this doesn’t scale up. We tend to talk about web “sites” and web “apps” as if they were clearly separated entities. In actuality, there’s a sliding scale between the two. At one end of that scale you’ve got traditional web sites with some added interactive goodness. At the other end, you’ve got full-blown applications that work like their desktop counterparts: they just happen to be on the web. For those kinds of web apps, it’s really, really hard to apply progressive enhancement because the behaviour and interaction is an intrisic part of the experience. In that situation, the key benefits of markup, CSS and JavaScript are, in my opinion, lost.

It’s entirely possible to build these kind of web apps using Ajax. In fact, that seems to be the first choice of developers these days. Inevitably, these apps require a lot of JavaScript, much of it written to make the code work cross-browser. It’s a lot of work, it’s a lot of bandwidth, and it doesn’t degrade gracefully. In these cases, Ajax stops being an enhancement and becomes a requirement.

If you’re going to make a specific technology a requirement for accessing your service, that’s your call. But here’s what I want to know: why Ajax? It strikes me as a precarious base level requirement. Your visitors need to not only have a modern browser with JavaScript enabled but, in the case of Internet Explorer 5 and 6, they also need to have ActiveX enabled.

There’s another technology out there with wider penetration and better cross-browser implementation: Flash.

Now, don’t get me wrong: I’m talking specifically about situations where you are going to have a technological barrier to entry in any case. I’m just suggesting that Flash is a lower barrier than Ajax.

Dan Webb voiced these same thoughts recently:

The sweet spot for JavaScript and Ajax has always been for those small, progressive enhancements rather than for creating rich interfaces. It seems to me that the more you head in that direction with JavaScript the more serious limitations you encounter. Browser JavaScript is never fast, has memory leak issues, browser bugs, CSS bugs and all manner of other tom foolery that, when you get to the stage of building something like for Google Maps gets really time consuming and messy.

He’s come to the same conclusion:

So yeah, I’ll be looking in to Flash and Flex then.

Of course there are other issues with Flash: it’s a binary format and it’s in the hands of Adobe. Personally, I’m hopeful that the format might be set free soon.

But the biggest issue with Flash lies in the minds of developers. For many people (and I was amongst them), the perception of the platform was formed a few years back and remains frozen ever since. A comment on Dan’s post illustrates this disconnect:

With Flash, you’re fundamentally excluding a huge chunk of your customer base… Clueless user with a new computer? No Flash… Google also won’t index your content if it’s all hidden in Flash… You’ve also got the whole issue of disabled people… AJAX, for all its flaws, works in any browser, for any customer.

All of these anti-Flash points might once have been true, but they’re very outdated now. The accessibility argument is especially galling. Recent versions of Flash allow for far more accessibility hooks than is currently possible with Ajax.

It’s only natural that some technologies are going to be used more than others because more developers are comfortable with them. However, the decision of which solution to apply shouldn’t be down to just the comfort level of the programmers: we should be using the best tool for the job. But when all you have is a hammer, everything looks like a nail.

So if you’re planning to make a bells’n’whistles web app that cannot be made to degrade gracefully, think for a minute before you automatically reach for Ajax. Take a look at Flash and Flex first. Then decide what’s best for the end user.

Posted by Jeremy on Monday, March 26th, 2007 at 12:53pm


Well, flash is not super-lightweiht either so the bandwith problem remains. I also wonder if it has real SEO possibilities. Moreover, flash is not enabled by default on several linux distributions and I guess it is three or four times more consuming to build the same app with flash rather than with a classic web framework - and the accessiblity hard-work is one of your key arguments.

# Posted by pangel on Monday, March 26th, 2007 at 1:55pm

I’ve been thinking a lot about this recently too, and have come to pretty much the same conclusion. The rings you jump through to deal with bugs and proprietary DOM and JavaScript implementations adds up to a heck of a lot of effort and cost. And then when you’ve finished you need a cutting edge machine and gigs of RAM to keep the experience as fluid as it would be in Flash.

Pangel, I’m not sure your arguments add up. Flash can have real SEO possibilities, (although I’d argue with a Flash application that SEO is not as important factor as with a content based web ‘site’), and for the reasons mentioned above I’d argue it’s not three or four times more consuming to build the Flash app.

My problem with Flash and Flex is the barrier to entry, and I’m talking about before I’ve even sat down to write any code. Getting the right tools and environments set-up and working, and the lack of simple things like ‘view bloody source’ make much of it seem a great mystery to me unfortunately. Then if I like it I have to shell out a whole ton of cash to buy it and continue learning it. I want to be bothered but it’s tough when the curve is so steep.

Anyone else feel like that?

# Posted by Andy Hume on Monday, March 26th, 2007 at 2:04pm

totally wrong 100% wrong, you make huge interpretation mistake from the beginning to the end.

argue 1 : dont use XHR, it needs activeX for IE5/6

answer : Dont Flash needs it too ? Worst of all, now with IE7 you got to click every time a flash file is playing. So your activeX argue is flawed.

argue 2 : don’t use js, the web should be a progressive enhancement

answer : probably (i’m not sure it’s true anymore) but Flash is not the best to this point, with Flash you got your tools or you got nothing. Doesn’t looks like an enhancement to me, not even progressive. Once again flawed argue. Flash is not degrading (gracefully) at all.

argue 3 : don’t use XHR, it’s bandwidth consuming

answer : Flash is consuming much more bandwidth than any JS/CSS/HTML combination will ever consume. Another point, the whole "ressources libraries" got to be (binary) downloaded with Flash when you only have to download needed ressources with JS/CSS/HTML (which will use cache, Flash will not).

argue 4 : use Flash, I (you) am hoping to see it open any soon

answer : XHR/CSS/HTML are already open and there’s nothing out there to prove (to be 100% sure) the same will happen to flash

argue 5 : don’t use XHR for you web apps, it’s too time consuming

answer : Flash app are much more time consuming to create and harder to maintain, especially when more than 1 developer is working on the application. How do you synchronize 5 ppl working on the same Flash app ?

argue 5 : don’t use XHR if it becomes a requirement.

answer : using Flash as a requirement is not a better answer. For instance, I dont have flash in any of my browsers excep for my old FX0.7. While XHR is much more accessible in all the others. Which one has the lower barrier now ?

argue 6 : Flash is more accessible than XHR

answer : well, that’s your call but you are wrong. How can you prove us a flash application will be more accessible than its XHR/JS/CSS/HTML equivalent ? Just telling us flahs is more accessible does not prove anything

Anyway everybody is doing the way it likes.

# Posted by Mokhet on Monday, March 26th, 2007 at 7:05pm

I pretty much agree with what Mokhet said, You’re pretty much wrong on every point - And I would say that it’s not a completely fair comparison. There are a lot of things that I would do with one that I wouldn’t do with the other, and vice versa.

There is an open source action script compiler here which is an order of magnitude faster than anything Adobe has dreamed up.

Argument: "The rings you jump through to deal with bugs and proprietary DOM and JavaScript implementations adds up to a heck of a lot of effort and cost."

Counter: Once you cross that bridge even once, you have all the tools you need to do it again. Creating a nice OO Javascript toolkit that you take from one place to another will be your best friend. To shoot down Ajax solely because you don’t want to do that is folly.

Argument: "the web should be a progressive enhancement"

Counter: Failover is an issue with the flash argument. If you don’t have flash installed (Ubuntu doesn’t come with it for example, neither does a fresh install of windows) you get nothing. You get a page chalk full of bubkis and nothingly-goodness. Where as if you have created your ajax application correctly, the links and what not should still work via a standard HTML page request.

Argument: "Recent versions of Flash allow for far more accessibility hooks than is currently possible with Ajax."

Counter: Ajax is fully W3C Compliant, Flash probably is as well.. but can you qualify this argument? I realize that there are some issues with HTML and accessibility ( but screenreaders like Fire Vox ( is way ahead and working on it. So I doubt your argument. Usually the problem is coders just don’t develop for it accessibility, not that it can’t be done.

# Posted by Palamedes on Monday, March 26th, 2007 at 9:15pm

(Part Two)

Argument: "It’s entirely possible to build these kind of web apps using Ajax. In fact, that seems to be the first choice of developers these days."

Counter: This is largely due to the fact that people don’t want to have to fiddle with the whole plugin architecture that ties you in to Adobe. Also I think a major sampling of users in general will point out a very large portion of the market just "hate" flash. Consider also licensing issues - some companies may not want to deal with tying themselves to Adobe…

Argument: "don’t use XHR for you web apps, it’s too time consuming"

Counter: Sometimes the only way to get information from the server is to poll. An XHTMLResponse whether done in flash or in ajax will take an amount of time to answer. Flash requires you to use XML doesn’t it? Where as Ajax you can use anything.. (I prefer JSON myself though xml works too).. either way sometimes the only way to solve something is to use an XHR and whether its 1k of xml to a flash app, or 1k of xml to an ajax app.. I don’t see the difference. In my experience, flash is slower to load initially though.

Argument: "But when all you have is a hammer, everything looks like a nail."

Counter: Wait.. You’re saying Ajax is the hammer? What does that make flash?

Now having said all that.. A lot of this misconceptions might be due to the fact that MANY of the ajax toolkits that are out there, flat out suck. Don’t use them. It’s sort of like back in the beginning days of Flash, all the flash toolkits sucked, and you shouldn’t use them.

In the end though, while flash can do all the same things that AJAX can do, in my opinion ajax does them better. If you’re going to write an ajax app, use ajax.

# Posted by Palamedes on Monday, March 26th, 2007 at 9:17pm

You have completely misunderstood what I wrote. I never said that Flash can degrade gracefully where Ajax can’t. I said if you’re going to lock people out anyway—by making a specific technology a requirement—then the decision as to which technology should be a requirement should be evaluated dispassionately. For some applications, Ajax is the right choice. For others, Flash is a better fit.

I fully agree that Flash has its issues, particularly with its proprietary nature. I’m not some Flash fanboy—far from it—but I’m not going to be so zealous as to turn my back on a technology when it might possibly be the best solution for the end user.

It saddens me to see people take such a knee-jerk anti-Flash stance without first investigating the facts (particularly the accessibility issues). I’m not going to list the points here; I’ll trust that you can research them yourself. I hope you’ll do so with an open mind.

# Posted by Jeremy Keith on Monday, March 26th, 2007 at 9:32pm

These are knee-jerk reactions which stem from years of bad design and bad use of Flash, and I don’t think we’re going to see the end of those as quickly as one might like.

But, in a sense, it’s not really important. I’m a huge believer in technology taking us where it wants to take us, if we push it far enough. Nobody here has all the answers, but if you believe in what you do, and prove it through practical application, then you are making history (be it right or wrong) - and that’s why I love this shit.

Flash? JavaScript? How anybody can fight for one over the other is beyond me. I’m just trying to build cool stuff, and I’m happy to use whatever seems right.

# Posted by Andy Hume on Tuesday, March 27th, 2007 at 12:48am

Having said that, Flash is at a huge disadvantage because it’s proprietary, difficult to get involved in, and expensive to persue and learn. So frankly, until it sorts that out, it can go fuck itself.

# Posted by Andy Hume on Tuesday, March 27th, 2007 at 12:57am

@Andy - Jeremy almost had me convinced until your last comment.

# Posted by Dean Edwards on Tuesday, March 27th, 2007 at 1:57am

Kyle was talking about this subject recently too:

# Posted by Matthew Pennell on Tuesday, March 27th, 2007 at 10:16am

Mokhet Are you a professional or amateur?

# Posted by Deren78 on Wednesday, March 28th, 2007 at 4:07pm

Jeremy, I wouldn’t worry too much about those people who’ve expressed horror at considering Flash: Emotional attachments to technology are an impairment to all facets of productivity and the ability to find good solutions. With such people reason tends not to be as effective without a shiny sales pitch or a friend who’s had a good experience.

You raise some very good points, and to be honest it took me a while to realise it because I suffer from a bit of tribalism when it comes to favoured techniques. From a user perspective, you are completely correct. An open mind can do us good.

However from a developer perspective it’s a bit more complicated. Flash is getting better but is still relatively opaque. It cannot be scripted, some amount of black box is still required.

I understand your premise - that the argument should be applied when some barrier is inevitable and we must choose the lesser of two evils - but even when that barrier is cleared, there is still an issue of accessibility. It’s very hard to work out what is going on with Flash, the tools are strict, and components are hard to isolate. For developers, especially multiple developers working on the same product, this is a serious negative.

# Posted by Barney on Thursday, March 29th, 2007 at 11:47am

Sorry, reading that over it’s not very clear: My point is that there is still an ‘accessibility’ issue, even when the technology barrier is cleared. In this sense AJAX can be a lot more accessible providing it’s intelligently designed.

# Posted by Barney on Thursday, March 29th, 2007 at 11:51am

# Posted by James on Friday, March 30th, 2007 at 7:50am

The accessibility of flash/flex for screen reader users is still limited, for some interface elements to be practically usable, JAWS users must first install JAWS scripts; "In order to most effectively use the JAWS screen reader with an Adobe Flex application, users must download and install scripts. " []. The support is also limited to JAWS with Internet Explorer and there also appears to be no documented support for other screen readers such as Window Eyes or Supernova.

# Posted by steve faulkner on Friday, March 30th, 2007 at 4:12pm

Great post, Jeremy. As you may know, I’ve also been beating the "Flash is not the devil" drum lately, and I’m talking about the subject of web standards and Flash at Future of Web Design with Florian Schmitt in a few weeks.

The bottom line here is this: use the best tool for the job. Sometimes, Flash is the best tool. If you disagree, then I’m doubtful you’ve been put in real world situations where this the case. I assure you, they exist.

The really interesting thing to me is figuring out how web standards and Flash can play more nicely together. There are lots of exciting things happening on this front, and we’ll be talking about some of them at FOWD.

Thanks for helping change the minds of designs and develoeprs who have been mis-trained that Flash is always bad, all the time.

# Posted by Jeff Croft on Friday, March 30th, 2007 at 9:55pm

Jeremy, I really enjoyed this post. I’m in the process of learning several web technologies including javascript and flash. Being relatively new to the web development scene it seems that many people are dismissing technologies that could lead to some of the most brilliant and breakthrough web apps/sites that we’ve ever seen. Google’s been doing it for ages (check out Google analytics to see some great implementation of flash).

For those of you that are "die hard" AJAX fans, why is a combination of flash and javascript out of the question? In certain situations the utilization of these two incredible technologies could produce revolutionary results.

Let’s see if we can plug the holes in both technologies by using the others. Use javascript where it’s strong and flash where it is accessible.

I grew up with the internet so I think it’s important to keep in mind that the technologies that we use today will probably be completely obsolete in a matter of years. They become obsolete because great designers and programmers work together and develop better solutions. Let’s do that instead of argue over the infallibility of our favorite software.

# Posted by Karl Peterson on Friday, March 30th, 2007 at 11:20pm

Jeff, Karl, I agree with you guys but I also see Andy’s point: as long as Flash remains a closed proprietary format, I (and many other developers) will never be able to embrace it with open arms. This isn’t a minor point: it’s a huge elephant in the room.

# Posted by Jeremy Keith on Friday, March 30th, 2007 at 11:31pm

This topic seems to be the third rail of front-end web development.

I’ve spent a fair share of time in Flash and now I’m spending as much free time sharpening my Javascript skills. The truth is, people should use what they feel comfortable with. Actionscript ain’t easy to learn, not to mention all the freakin’ bugs in Flash. However, Actionscript 3.0 and Flash CS3 look pretty damn nice. Flash gets a bad wrap and mostly by people that don’t know how to use it. Ironic.

There is A LOT of bad Flash out there and my message to the curious, if you’re gonna do Flash don’t make it obvious. Flash gives developers a lot of power over the interface and with great power comes great responsibility.

I think the coming year will be interesting. Good to hear your curiosity has been sparked :) We need more discussions on this.

# Posted by Nathan Borror on Saturday, March 31st, 2007 at 12:09am

On the point of Flash being proprietary and such…I think everyone would agree the driving force for Flash in the last year or two has been video.

Someone tell me how I can display video on the web in a way that isn’t proprietary. QuickTime? Windows Media? Real Player? Right, there’s no such thing. No matter what video format you choose, you’re stuck with a proprietary player. There’s no such thing as a web standard for video.

And so, Flash has become the de facto standard for video on the web. But here’s the thing — as soon as a site decides to use Flash for video, they’ve imposed a requirement that their users have Flash in order to experience all their content. And once you’ve introduced that requirement, it’s really easy to say, "well, our users already have to have Flash…maybe we should use it instead of JavaScript for such-and-such. Maybe we should use Flash instead of JavaScript to display these maps we’re showing. Maybe we should use it for this photo uploading tool we have. After all, our users already have to have Flash, and Flash is more consistent and reliable than JavaScript from browser to browser."

My point is — the lack of a really good non-propriatary format for web video is what’s propelling Flash right now. And the more Flash gets propelled by video, the more ubiquitous it becomes. And the more ubiquitous it becomes, the more people are going to use it — for video or otherwise. Flash becomes the best tool for the job by way of it being more ubiquitous, more consistent across browsers, and more regularly updated than JavaScript. And video is driving that.

So while it’s true that Flash technology is owned by one behemoth corporation, it doesn’t really matter. Because so is QuickTime. And so is Windows Media. And so is RealPlayer.


# Posted by Jeff Croft on Saturday, March 31st, 2007 at 12:56am


You make a very good point, but still, I think you underplay the lock-in that comes from being bound to a proprietary format. I completely agree that video is a proprietary playing field anyway, but I don’t know that I’m comfortable drawing the same conclusion — well, we’re using it for video so let’s put everything interactive in Flash. When a company gets that kind of lock-in, it could discontinue a particular version entirely. Remember the wailing and gnashing of teeth when MS killed VB6 for VB.NET.

You could counter argue that it was a bad move for MS, that people defected to Java, Python, or something else, but it was the developers (or their companies) that had to sort out the mess. Would this ever really happen with Flash? No one really knows. You are, however, dependent on Adobe for continued development on any product in Flash. Having a reasonable dependency on Flash is one thing, but a complete lock-in across much of your site just because it’s available may not be wise.

Don’t get me wrong, we’re using Flash all over the place where I work. I think we’ll continue to push its use, too. I agree with the larger point that we shouldn’t be snobs about HTML/CSS/JavaScript, that Flash is better in certain respects, but when thinking about how and where to use Flash, it’s worth considering your dependency on Adobe in your decision making process.

# Posted by Deryck Hodge on Saturday, March 31st, 2007 at 2:54pm

Flash 9 is improved. Flex makes Flash a lot better for most "GUI" things. Apollo improves on all the Flash, Flex, and HTML things. This is proprietary, but not expensive, and the right direction for web-based applications.

If nothing else, all this from Adobe should put pressure on the browser vendors and standards organizations to improve their pretty bad (given its age) set of technologies.

# Posted by Patrick Logan on Monday, April 2nd, 2007 at 1:23am

I’m no expert, but isn’t the AS3 virtual machine the most faithful implementation of the ECMAScript 4 spec available? I believe it’s going to form the basis of Tamarin, the new Javascript parser in Mozilla.

Considering that there is an active open-source Flash community ( and Adobe seems to be making inroads in the areas of standardisation and accessibility, I think any developer who slams the door on Flash/Flex is cutting off their nose to spite their face.

# Posted by Marc George on Monday, April 2nd, 2007 at 11:28am

After playing with Flex for a few days, I’ve written a few more thoughts here:

# Posted by Andy Hume on Sunday, April 8th, 2007 at 12:50pm

I think it is important to cosider the "degrade peacefully" issue. When you combine many of the ajax and other technologies it often spells disaster for several apps at once. Recently while music through yahoo messenger I notcied that opening several ajax enabled pages in the tabs of my firefox, that it eventually all froze up, forcing a complete restart.

Releasing memory and cycles should be a focus for all developers.

# Posted by Wendy on Wednesday, April 25th, 2007 at 3:45am

Sorry. Comments are closed.

March 2007

Recommended Reading

XML Subscribe

Grab the RSS feed for this blog.

JavaScript API

Grab the RSS feed of comments for this entry.