The web development industry is justifiably excited about Web 2.0, but why no mention of Macromedia Flash? Don't get me wrong, Web 2.0 and AJAX is a good thing, probably even a great thing, but it's not the only solution to the problem at hand , nor is it even the best solution for many applications.

 

Several years ago when the Macromedia Pet Market application (http://www.macromedia.com/devnet/blueprint/) was launched I was astounded. The company I worked for was a one-eyed Microsoft Active Server Pages shop (and I guess, by extension, I was a one-eyed Microsoft developer) so of course, we'd never seen anything like it.

 

If you haven't seen the Pet Market, basically, it's a full featured whizz bang demo website built by Macromedia for showing off the capabilities of Flash. It uses advanced widgets such as accordions , datagrids, child windows (kind of like MDI child windows in the sense that they can be dragged and resized around the screen), has drag and drop and utilises server side method invocation without postbacks.

 

 

Now, to fully comprehend the situation, you have to realise there was some politics going on at Macromedia that probably influenced the development of the PetMarket site. Both Microsoft and Sun Microsystems were fiercely embroiled in a statistical benchmarking war over which server platform was more scalable.

Sun, originally developed a "Pet Store " application to show off the capabilities of J2EE.
(http://java.sun.com/developer/releases/petstore/index.html)


Microsoft countered by developing their own Pet Shop to show off their wares.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet.asp)

And this resulted in a lot of to-ing and fro-ing over whose architectural platform was faster, scalable etc.

Now whilst the two technologies are substantially different on the server side, J2EE and ASP (or ASP.NET) applications are indistinguishable to the average end user of the website. More specifically, they're a bit boring.

So impressed by the whizz bang user interface effects, I forwarded a link to the Macromedia Flash PetMarket site on to several colleagues from Microsoft to find out what the "Microsoft response" would be, and inadvertently ignited a friendly, but fierce debate.

 

The end result produced by Flash was clearly superior. Both the pure ASP.NET and J2EE server side Pet Shop applications simply didn't compare to the beautiful, interactive UI that Flash offered.

 

But the folks from the "how you get there matters" camp, had a valid point - Some suggested that Macromedia were "cheating" because Flash requires an ActiveX control download and anyone could achieve the same result by writing binary (and by that they meant Win32) code, such as the now defunct Dynamic HTML applications you could build in Vb6.0.

Certainly cutting code in the animation-oriented Flash development environment was undeniably difficult to transition to for the average Visual Studio/Visual Basic trained developer. This has improved somewhat by the way, with the introduction of "Flash Applications" in MX2003, but it's still a valid point today.

 

The rest of the argument isn't really relevant here. What's important to note is that architecturally speaking, Macromedia's Flash product was and is, Web 2.0.

 

Flash certainly has a dynamic, highly responsive user interface. In fact, the user interface is where Flash really excels. Instead of cutting JavaScript and Dynamic HTML code, you're writing ActionScript or quite possibly not writing any code at all, since animation is inherently supported "code-free".

 

For dynamic user interface operations, such as sorting tabular data, or resizing the columns on a grid with thousands of rows, Flash is far superior to the JavaScript/AJAX equivalent. The performance comparison differs by an order of magnitude.

Flash not only supports postback-free synchronous and asynchronous communications, but provides multiple options for retrieving and sending data to the server, ranging from simple LoadVars calls to full application server product lines designed just for this purpose.

 

Flash is more cross browser and cross platform than probably any product in the world. The average Flash application will behave much more predictably across platforms than any Web 2.0 application written in JavaScript and AJAX.

 

(Ed note: In fact, the average Flash application behaves better than many straightforward HTML websites, let alone Web 2.0. I'm getting JavaScript errors whenever I browse ESPN's website....)

 

And what about bandwidth conservation? The initial download for Flash is miniscule. It's downloaded once, no matter how many different websites you browse to that utilise Flash.

AJAX is an entirely different animal. The AJAX javascript libraries are often not only bigger than the highly compressed Flash Player to begin with, but they will be downloaded for each and every AJAX web site you browse to.

For example, Microsoft's ATLAS libraries are currently around 500kB and they're not complete yet. This may be a significant factor for applications where bandwidth is limited, expensive or constrained by an SLA with a max cap on page sizes.

And during online application usage, well architected Flash applications can use less bandwidth than AJAX applications because of the computational power of Flash itself.

Now of course, every silver lining has a cloud, and Flash has it's fair share. The biggest downside for ASP.NET developers will be the animation oriented Flash development environment itself. It's a poor substitute for Visual Studio.NET on a number of levels. Without performance monitoring, Intellisense, code completion and a host of other features it's not well suited to code intensive applications.

Macromedia have made strides to integrate a Flash front end with a Java or .NET middle tier and back end, but the level of integration will never be at the same level as the native development environments.

I guess the moral of the story is there's always a better technology out there, a better way of writing your applications. The user interface can always be improved. The performance and scalability can always be tweaked. If you're moving to Web 2.0, don't forget about Flash. If your team has the skillset (and your clients allow you to cut Flash code), then you may well end up with a more polished, scalable result.

Using CrunchyCode allows you to try numerous different techniques against your own database, without manually coding anything.

You can assess the pros and cons of different technologies from different vendors. By building multiple applications simultaneously, without you (or your team) lifting a finger, you can pick the user interface and coding styles that best suit your dev team and business requirements. You can measure the performance impact of implementing different technologies on large recordsets, small recordsets, high volume, low volume, usage patterns and much more