Why a Flash vs Ajax Debate?
I've been wondering for a while why Ajax has become so popular recently, when Flash has had the same capabilities and more for several years. I've been working with both JavaScript and Flash since 1999, and for me, there's never been a debate over which was the superior technology. I avoided JavaScript when possible, mostly because cross-platform compatibility was my prime directive, and because it was possible to do things in Flash that JavaScript was incapable of. For a long time, the Flash Player was more ubiquitous than the presence of advanced JavaScript capability.
Today it seems to me that the Flash Player and advanced JavaScript capability are almost on an even footing in terms of ubiquity (I say this based on user agent stats I've seen from a few different market segments). When you consider that MSIE 6 can make up 90% of the traffic to a consumer-oriented site, that's a pretty good chunk of it. Then, you've got the IE 5.x's, the Firefox's and the occasional Safari. Really, the browser that can't do Ajax is increasingly rare.
I still believe Flash is superior, in many ways. But ironically, the things that used to be its main strengths are becoming liabilities.
I used to rely on Flash because it reduced my testing effort. With Flash, I could be basically assured that what worked on PC IE would work on Mac IE (no small feat, by JavaScript standards). Unfortunately, over the last several versions of the Flash Player, many obscure bugs have come and gone, bugs that existed for perhaps only one minor version of the Player on one browser. I recall one particularly egregious bug in Player 6-dot-something for Mac IE, where you could not cancel a loadMovie request once it was made (hogging up bandwidth to an unusable degree, in my case).
Fortunately, Macromedia was great about fixing those bugs. Unfortunately, the public was not so great about updating their players. These days, if you want to reach that 97% audience that Adobe advertises, you have to target Player 6. I recently came across a scenario where the company-wide IT policy was Player 6, no hope of upgrade (in some companies, shockwave is just completely blocked at the firewall level).
[As a long-time Flash devotee, I cringe while writing the following]
The upshot of all this is that Flash represents a multiplication in testing effort for every back-version you target. Even some of the simplest tasks, such as Local Shared Object read and write, can not in my experience be relied upon to work identically across all minor player versions back to 6.0. If you want to make a compatibility promise, the only way to do so is to test every feature of your application in every version of every targeted browser, in every minor version of the Flash player going back to the targeted version.
To put that in perspective, there are 6 releases in the Player 6 archive, and Player 7 had 7. Let's ignore Player 8 for now. Let's suppose we want to target MSIE 5 and greater, Firefox 1 and greater, and Safari 2 and greater. That's at least 3 versions of IE, at least 3 of Firefox, and probably 2 of Safari (I'm speaking loosely here, I'm sure there are more). That makes 8 browsers to test on, and 13 versions of the player - a total of 104 test configurations.
Yikes.
No development team in their right mind would take on such a testing effort, even for a mildly involved project. (Now, I'm not suggesting that you have to - you can definitely achieve high quality products in Flash without all that. But to be precise, you can't make a cross-platform compatibility promise without actually testing on all targeted configurations.) Compare this to JavaScript, where you have only the browsers themselves to concern yourself with.
Now, I have never tested a complex application in every minor version of the Player, and more often than not, the cross-platform compatibility promise of Flash does hold true. But I have also had situations where bugs didn't present themselves until the product was launched and customers complained. Those situations have made me very cautious, and even though I don't test all the minor versions, I do end up with longer QA cycles on my Flash projects than the JavaScript ones.
Not that testing JavaScript-based apps is easier: there tend to be more unanticipated bugs than in Flash, so I probably end up with more QA cycles.
Ultimately, Flash can still do way more than JavaScript, and I firmly believe it remains a better solution for RIA. But I don't think Adobe can rightfully trumpet cross-platform compatibility and player ubiquity in the same breath. If you want all the considerable advantages that the Flash Player has to offer, you have to sacrifice some market penetration. If you want 97% reach, you have to author for Player 6 and test like mad.
One thing Adobe could do to help the situation would be to publicize the bug databases from old releases of the player. That would at least allow us to know what we're dealing with when developing for older player versions. A lot of the bugs that have given me the most grief in the past were only documented in the Flashcoders archives, and only in the ad hoc format of a discussion thread.
I have had a hard time understanding why so many developers were so keen to jump on the Ajax bandwagon when Flash has been around so much longer. Maybe this testing effort thing has something to do with it. Am I onto something here?
Today it seems to me that the Flash Player and advanced JavaScript capability are almost on an even footing in terms of ubiquity (I say this based on user agent stats I've seen from a few different market segments). When you consider that MSIE 6 can make up 90% of the traffic to a consumer-oriented site, that's a pretty good chunk of it. Then, you've got the IE 5.x's, the Firefox's and the occasional Safari. Really, the browser that can't do Ajax is increasingly rare.
I still believe Flash is superior, in many ways. But ironically, the things that used to be its main strengths are becoming liabilities.
I used to rely on Flash because it reduced my testing effort. With Flash, I could be basically assured that what worked on PC IE would work on Mac IE (no small feat, by JavaScript standards). Unfortunately, over the last several versions of the Flash Player, many obscure bugs have come and gone, bugs that existed for perhaps only one minor version of the Player on one browser. I recall one particularly egregious bug in Player 6-dot-something for Mac IE, where you could not cancel a loadMovie request once it was made (hogging up bandwidth to an unusable degree, in my case).
Fortunately, Macromedia was great about fixing those bugs. Unfortunately, the public was not so great about updating their players. These days, if you want to reach that 97% audience that Adobe advertises, you have to target Player 6. I recently came across a scenario where the company-wide IT policy was Player 6, no hope of upgrade (in some companies, shockwave is just completely blocked at the firewall level).
[As a long-time Flash devotee, I cringe while writing the following]
The upshot of all this is that Flash represents a multiplication in testing effort for every back-version you target. Even some of the simplest tasks, such as Local Shared Object read and write, can not in my experience be relied upon to work identically across all minor player versions back to 6.0. If you want to make a compatibility promise, the only way to do so is to test every feature of your application in every version of every targeted browser, in every minor version of the Flash player going back to the targeted version.
To put that in perspective, there are 6 releases in the Player 6 archive, and Player 7 had 7. Let's ignore Player 8 for now. Let's suppose we want to target MSIE 5 and greater, Firefox 1 and greater, and Safari 2 and greater. That's at least 3 versions of IE, at least 3 of Firefox, and probably 2 of Safari (I'm speaking loosely here, I'm sure there are more). That makes 8 browsers to test on, and 13 versions of the player - a total of 104 test configurations.
Yikes.
No development team in their right mind would take on such a testing effort, even for a mildly involved project. (Now, I'm not suggesting that you have to - you can definitely achieve high quality products in Flash without all that. But to be precise, you can't make a cross-platform compatibility promise without actually testing on all targeted configurations.) Compare this to JavaScript, where you have only the browsers themselves to concern yourself with.
Now, I have never tested a complex application in every minor version of the Player, and more often than not, the cross-platform compatibility promise of Flash does hold true. But I have also had situations where bugs didn't present themselves until the product was launched and customers complained. Those situations have made me very cautious, and even though I don't test all the minor versions, I do end up with longer QA cycles on my Flash projects than the JavaScript ones.
Not that testing JavaScript-based apps is easier: there tend to be more unanticipated bugs than in Flash, so I probably end up with more QA cycles.
Ultimately, Flash can still do way more than JavaScript, and I firmly believe it remains a better solution for RIA. But I don't think Adobe can rightfully trumpet cross-platform compatibility and player ubiquity in the same breath. If you want all the considerable advantages that the Flash Player has to offer, you have to sacrifice some market penetration. If you want 97% reach, you have to author for Player 6 and test like mad.
One thing Adobe could do to help the situation would be to publicize the bug databases from old releases of the player. That would at least allow us to know what we're dealing with when developing for older player versions. A lot of the bugs that have given me the most grief in the past were only documented in the Flashcoders archives, and only in the ad hoc format of a discussion thread.
I have had a hard time understanding why so many developers were so keen to jump on the Ajax bandwagon when Flash has been around so much longer. Maybe this testing effort thing has something to do with it. Am I onto something here?
7 Comments:
As you mentioned yourself, there are always a few who can't use either technology, so you have to develope a fall back version anyhow.
Under that assumption it is a lot easier to target just a specific release of flash, sending the rest to the fallbck solution than doing the same with JS.
And still (even though I do understand your point) with browsers the testing is a lot harder, not only didn't you mention Opera, and Konqueror etc. also there are differesnces between the same version of IE on win2000 and XP, not to mention winME, whereas I cant recall any problem with an swf working one the same player, regardless of IE version or differences between the same player on firefox and Opera.
Running different versions of IE on one machine is an other problem.
As targeting 100% just isn't doable, with Flash testing the major versions of players in 4 Browsers on 2 OS, looking out for (the compared to js very few) known issues is reasonable, with dhtml/ajax even very harmless things force me to test extensivly on more browsers, more OSes to get only close to the 98% certainty I get with Flash.
And unlike Flash there have always been a lot of workarounds to be used, which makes it very hard to maintain that js stuff.
I do second your point on Adobe publishing known bugs, and I do understand what you want to say though.
I build e-learning applications and once we have agreed on a minimum flash player version 6.0.x (or whatever the client agrees) the whole application is tested on every platform using every target browser agreed with the client. And I wouldn't expect it to be any other way.
I would be interested in seeing what kind of testing matrix ajax developers use to test their applications.
One advantage that I can see that AJAX has over flash is that it can become any height and is much better at flowing content than flash is.
Although flash can be a very rich experience at a fixed aspect ratio, AJAX apps win hands down on scaleability in the browser and being able to make use of increased demands on screen real estate.
We use the combination of VMWare virtual machine installations ( does not support Mac, och) and Plugin Swticher tool to test our Flash based application using 4 main test configurations:
1) main
XP+SP2+IE6.0+FP8
--------
2) based1
XP+SP2+IE6.0+FP7
--------
3) based2
XP+SP1+IE6.0+FP7
--------
4) based3
XP+SP2+IE7.0+FP8
--------
Coming from a JavaScript perspective, I found ActionScript to be more of a hassle than writing cross browser JavaScript – this of course is partly because of experience, but there were a number of other strange things about AS. Why are there still no regular expressions, for instance?!
I also find it hard to imagine how to build an application with just Flash, as the server constantly needs to prepare specially packed data for the Flash to render – with an "Ajax application" the server only needs to spit out HTML which can be injected into the page. Sounds a lot easier.
Again, I'm a relative Flash novice (sIFR 3 is the first time I ever used it), but it all seems quite hard. The evolution from, say, a weblog system to a web application with forms etc seems easier than going to Flash, too.
In response to Mark Wubben, Flash 9 has regular expressions support, and it's great! It should be officially released within a couple weeks.
Secondly, while being able to spit out HTML to AJAX is easier, I believe it would be better to send a generic XML response just like you'd send to Flash. In small projects, it doesn't really matter, but for larger projects it's be better to be flexible. If the HTML layout changes in the future, you may have to rewrite that particular part of the server functionality to match. Similarly, you might you start targeting other platforms in the future (perhaps some that won't expect HTML, but simpler XML).
More on topic, personally, I've had more trouble targeting browser implementations of JavaScript vs targeting versions of the Flash player. However, I believe that's becoming less and less relevant and the number of cross-platform JavaScript libraries increase.
One important thing is that Flash is not search engine friendly. While you can still get No. 1 on google search with a Flash site, that will require more SEO efforts compare to normal Html sites.
Of course, if the ENTIRE website just created with Ajax (meaning there is only a single url, and all the interaction is created with javascripts and ajax), then Flash is definitely a much better choice as it is much more maintainable (depends on the developer too, if he dumps everything in keyframes and buttons then its not).
On the other hand, if the website model is very much like Flickr, then Ajax is the way to go. But for a site like live.com, then www2.goowy.com does a much better job with Flash.
Sometimes it is not the question of the developer's convenience, but business constrains. If I dun nid to care about bookmarking, seo and security, I will go for flash all the way.
Flash player on a Mac still returns a weird long number if you accidentally divide by zero.
Post a Comment
<< Home