Flash vs HTML. It's reminiscent of the Netscape vs Microsoft browser wars of the late 90's. Both technologies have a place in any developer's toolkit but for all the shouting across the blogosphere it's the client and their project requirements that determine which route works best.

Flash itself offers a fantastic channel for delivering video, audio and 3D based content as well as allowing multi-platform compatibility for websites and digital applications which would be difficult, and in some cases impossible, to deliver in HTML/CSS/Ajax. Given that it has wide support on a range of desktop and mobile devices across the world with an almost universal number of users it seems like a no-brainer for client projects right?

Unfortunately, even with everything it possesses, flash has a number of serious drawbacks:

Even with all the improvements that Adobe and search engine providers have made in indexing flash SWF files it is still difficult to optimise flash sites/files for SEO purposes. Not that it's impossible but the process is a lot more convoluted and involved than optimising HTML pages. This requires more time, which means more cost and the results of Google's SWF indexing do not compare to those of standard HTML based files. That doesn't translate well with client's who are looking to rank as highly as possible in the search engine result listings.

It requires a plug-in to allow flash based content to be run on user's computer devices. This presents barriers to some user's who may not wish to install a plug-in, don't want to spend time downloading and installing the plug-in or may not even know what or why they need the plug-in. That means your flash based website is skipped over as the visitor heads elsewhere.

Breaks usability and expected conventions. For example, if you are navigating between pages of a website you can simply use the backwards and forwards buttons on the browser. In most flash sites this behaviour is cancelled as the flash site sits in 1 single HTML file. Once the user clicks to go back they are taken out of the website and to a previous non-related page (assuming they did not go to the flash site first.)

Some flash sites however implement a technique called deep dynamic linking which does allow for various SWF files to be navigated between using the browsers backwards and forwards buttons. Unfortunately this adds another layer of time and cost to engineer into the website. And for what end? To replicate a behaviour that is natural with HTML based websites.

Hardware issues. Flash performs poorly on older systems and on Apple Mac computers. This is a particular source of contention across the blogosphere at the moment with many developers arguing backwards and forwards.  The fact is though that non-flash technologies like jQuery, HTML, css and ajax are able to replicate a certain amount of flash's functionality without the bandwidth/CPU overhead that accompanies the use of that technology.

Accessibility. Despite Macromedia/Adobe's efforts to make flash easier for screen readers and assistive software to use it still doesn't compare to the ease of achieving the same ends with HTML. Not to mention, according to W3C guidelines, that requiring the use of a plug-in to access content immediately presents barriers to accessibility.

Loading times. Flash content can be optimised for more efficient loading but it still requires that all content be loaded before the web page/application can be accessed.

We're not trying to bash flash too heavily here as it does have some fantastic capabilities (interactive video support, 3D integration and mobile device support to name a few) but the days of building entire websites with that technology are very firmly in the past for most client projects. The need for search engine optimisation and accessible content combined with project deadlines and budgetary considerations means that for most business websites flash isn't even an option.