The Flash vs HTML5 debate

Lately everyone seems to be chiming in on the Flash debate now that Steve Jobs has announced that the iPad does not support flash and probably never will, as long as they don’t have access to the Flash runtime. Apple’s reasoning behind the Flash ban has been that it is processor intensive and thus would kill battery life and provide a slower, poorer user experience in the web browser. Their other gripe is that exploits and bugs can be caused by Flash and they would have to be at Adobe’s mercy to fix them (nevermind that this doesn’t seem to be a problem for the desktop).

What touched off all the controversy is that Jobs stated that the world is moving towards HTML5 (which is true, but with caveats).  HTML5 promises to add features that web developers have typically had to turn to Flash for – namely the ability to do richer client side coding through realtime drawing, better support for vector based graphics formats (SVG) and a generally cleaned up tag model. It also features tags for playing video, which is one of Flash’s main claims to fame.

HTML5 is great, and it will definately save web developers a lot of time and allow for richer interfaces. However, it still has a long way to go. Early performance tests indicate that Flash still has a big advantage on rendering. Video playing via html5 is still dicey since different browsers support different video codecs. And probably biggest of all, IE doesn’t support it yet and will probably do a less-than-stellar job once it does support it.  Firefox, Safari and Chrome all have varying levels of support.

HTML5 also does not have the advanced editing tools yet that Flash does. Doing the same level of animation, coding, and polish will be difficult with HTML5, for quite a while.

What HTML5 does have is that it is an open standard, supporting mostly open file formats, which means that a number of devices and manufacturers can support it if they invest in doing so. The other side of that is that this brings with it the same cross-browser implementation issues that have cost developers untold amounts of time since the beginning of the Web. One thing that works in Firefox will invariably break in IE or not show up in Safari. It’s easy to blame specific companies for poor implementations of standards, but the fact remains that different companies will always do things a little bit differently and that will cause problems (unless you have a rock solid spec). It’s just the way it is.

The people suffering the most from not having Flash support are probably online advertisers. Without Flash, they are forced to serve more prosaic image-only ads. For them to support HTML5 as an ad standard, would require developing new products and infrastructure around it (something they have typically been slow to do). Standardization among advertisers is often slow to crystalize too.

To sum up: actions by Google and Apple have definately helped speed things up, but  HTML5 still has years to go before web developers can target it as a viable alternative to everything Flash can do.

Claims that the iPad and iPhone will kill flash are generally inflammatory and not really grounded in reality. Flash is still installed on 99% of desktops. Until HTML5 can offer a better experience to 99% of the people, and shorter development time for the same user experience, it will not be worth it to switch. Mobile / no flash versions will still need to be developed, but that’s nothing new for web developers.

All that said, Adobe does need to respond to the cricism leveled by Apple, since it’s criticism that has been around for years. Flash is a closed format, and rendering speed is generally very poor in comparison to what it could be with proper hardware acceleration. People also have a bad taste for flash just because of how a lot of developers have chosen to use it. Web sites that are slow, difficult to navigate, or generally ugly or unusable contribute to people’s negative perceptions of what Flash is.

Adobe can respond in several ways.

• They can open up the Flash format so that other companies can start to develop their own players. Adobe has already started this process with the Open Screen Project, which allows manufacturers to write intermediary code necessary to display flash on different devices. It does not open up the entire file format. Hopefully Adobe will go down this path.
• They can optimize their rendering. Flash has always been hamstrung by the fact that it is a software-only renderer and thus cannot use hardware optimization to speed up drawing. Adobe should develop a newer version of the flash player that can shed some of the software specific features and allow their developers to write rendering code that can run under OpenGL and DirectX. This may mean sacrificing the rendering of strokes and curves exactly as they are rendered now, but in the long run it will be better for everybody. This will make Flash on the majority of netbooks and other devices more efficient and be easier to provide out of the box (without specific code written for each device).
• Adobe can provide better out of the box user experiences for Flash. For the iPhone, Apple has UIKit, which has ensured that the majority of iPhone apps have a similar UIs and adhere to interface standards. Flash has always been the wild west as far as interfaces go. Built in components typically suck, are inefficient or generally aren’t usable or expandable in the ways developers need. This forces everyone to develop their own stuff, which in turn leads to inconsistent UI’s and higher learning curves for users. An official, well thought out, comprehensive UI framework for Flash websites and applications would help improve this negative conception of Flash UI’s.

These are the features which would mean the most for the future of Flash – hopefully Adobe is listening.