In some ways the content of this post is related to the recent Flash / Mobile snafu. Specifically because Adobe have made a big point of throwing their weight behind HTML5 in place of Flash on mobile platforms. This post is derived in part from personal experience and in part from a lively (and occasionally heated) debate with a colleague. In short it deals with my concerns over the dropping Flash support in favour of HTML5 and the common perception that anything Flash can do HTML5 can do (better).

I appreciate that HTML5 is still technically under development and that many of the issues raised here may be resolved in the future but I’m making this comparison based on current features and support as of Q4 2011.

Lets run through some common use cases for Flash on the web and take a look at the HTML5 equivalent:

Video / Audio / Device Access

For almost a decade Flash has been the go to guy for web developers needing multimedia content on their websites. Video and audio players abound and Macromedia / Adobe put masses of work into pairing with codec providers to push the envelope for on-line video. The end result, from a Flash perspective, is a relatively simple platform that requires a single codec (leaving aside iOS devices for the moment) to reach most of the worlds internet users.

Audio is a similar story – need to play an MP3 on your site? Use Flash.

Device access is has only recently come to the fore but the ability to have your web application access a user’s web cam, microphone or other attached devices has massive potential turning the net into a two way multimedia exchange.

Now HTML5 purports to provide support for all of the above and the browser developers are doing a great job. The <video> and <audio> tags have a nifty API that actually make it simpler to work with multimedia. Likewise, having device access directly exposed to your scripting layer is much neater, simpler and more powerful than having to hack the data out of Flash.

But there’s a problem.

A couple of problems in fact! Firstly, there is currently no single codec for HTML5 video that allows you to target all devices. That’s a major buzz-kill. Transcoding video is expensive and time consuming (not to mention the issue of loss of quality) and storing two copies of every video is at best irksome and at worst requires complicated scripting to determine what video file needs to be supplied to what user agent. All of a sudden the lovely simplicity of <video src=”blah.vid” /> isn’t looking quite so appetising.

Worse, the codec that looks most likely to arrive browser wide is an old friend – H.264 – a closed video codec with patent liability and proprietary IP issues following it around like a bad smell. The “open” Ogg Theora codec isn’t supported on Safari or Internet Explorer and isn’t likely to get buy in from the stakeholders at Apple or Microsoft. Oh and Google have apparently decided that the best way to solve this issue is to … develop another video codec which has similar patent issues as H.264. In short, the whole codec confusion makes HTML5 video very unappealing to those looking to produce video on the web when compared to encoding and uploading a single FLV file.

The second issue is more contentious. At this time HTML5 video does not provide any automated way for content providers to protect their content, no DRM, no source obfuscation, nothing.

Like it or loathe it*, DRM is a big part of convincing content producers to allow their work to be used on-line and with no HTML5 video (or audio) support for it providers will have to rely on fragmented, codec or user agent specific methods to secure their content. Hell, they may even have to get you to install a plug-in to view their video content … oh … wait …

Device access is something HTML5 handles as well as the flash platform but aside from that, multimedia playback has a long way to go before it’s up to Flash standards in terms of business feature set and simplicity of deployment.

Games & Interaction

I did my first ever piece of HTML5 canvas animation a short while ago and found the experience to be fulfilling. But it also exposed a massive gap in HTML5′s ability to build rich interactive applications.

Canvas is not interactive. It has no native facility for interaction. It has been built as a read-only … well … canvas for animated elements. And even within that has some pretty major limitations when compared to animating via the Flash platform.

Building interactive animations (think Flash navigation headers) that combine animation and interactivity are common on today’s web and the HTML5 equivalent, whilst possible, takes a lot more work to develop. In short, HTML5 doesn’t offer a single solution to the common client requirement to blend video, animation and interaction and, more worryingly, there’s nothing in the specification that could be extended to fill this void.

Then we come onto games. 2D, 3D it doesn’t matter Flash is the king of on-line fun time. Yes guys like Rob Hawkes are making massive inroads in the sphere of pure HTML5 games development and there are some HTML5 game development tool kits starting to emerge that allow developers to focus on building their games rather than wrestling with fairly complex scripting and DOM manipulation but this area is still in its infancy and has a way to go before it can offer the all in one experience of Flash game development.

Rich Internet Applications

The business end of Flash which has received masses of love from the likes of the Flex framework and, in my opinion, the lest suitable use for Flash in a modern world is also, fortunately, the closest to being solved by HTML5 technologies.

Lightweight mark-up, AJAX and web sockets have the potential to build faster, lighter web apps with more scope than ever before and, by encouraging exposure of data in interchangeable formats (JSON, XML, who cares provided it’s open) mean that the web can truly come into its own in this arena. Flex devs are going to dislike my saying this but, with the exception of some of the shiny stuff, HTML5 can already be used to build equivalent dashboards and rich applications when set against the Flash offering .. provided you don’t want too much animation or multimedia support of course.

So how do you solve a problem like HTML5?

I suppose the first question is should we solve these problems? Yes, yes a googol times yes. Whilst I’ve identified some of HTML5′s shortcomings when compared directly against the Flash offering please don’t think that I don’t believe HTML5 is the way to go. Having interactive, rich content on the web at the mercy of a single company is a universally bad idea and the work the HTML5 team and browser developers are doing is much needed!

The bigger reason to ensure we fix HTML5 as a platform is that the largest emerging internet market has no more flash support – mobile is already huge, it’s only going to get bigger and we need to be able to develop in a single, coherent system for both desktop and mobile because that boundary … it’s going to get real blurry real quick!

That said, the current HTML tool set does need work. We need to focus on moving towards a single video / audio codec for delivery of multimedia. We need more work done in developing frameworks for developing complex HTML5 animations and interactions and we need to continue promoting the web as a capable tool for RIA development and we need to encourage the stake holders to start agreeing on standards to minimise fragmentation in the emerging solutions.

I’m optimistic that most of the issues outlined above will be resolved over time but as things stand HTML5 has a long way to go before it can claim to be a viable replacement for Adobe Flash.

* Personally I’m of the hippy-esque approach that all data should be free and that DRM is a waste of time … I also appreciate that I’m an idealist in this regard and a DRM free universe is never going to happen.