HTML5 Vs. Flash. What You Haven’t Heard.

Editors Note: This is a guest post by Carlos Nazareno, an interactive media artist with a great deal of flash experience. He felt he had an interesting take on the Flash vs. HTML 5 saga and we agreed, we hope you will too.

When Apple unveiled the iPad in January, its glaring lack of support for the Flash browser plug-in ignited heated HTML5 vs. Flash discussions. At the heart of the debate is the idea Flash will become obsolete as HTML5 duplicates much of its functionality. As a developer who works with the Flash platform, I’d like to point out a few things about this new Mac vs. PC-esque debate that just won’t quit.

The Web is ruled by designers not developers.

What HTML5 promises to bring is the rich interactive web in the future: the same whiz-bang object animation, tweening effects, and video that have long been the domain of Flash. One thing anti-Flash proponents have to realize however is that the web is ruled by designers who don’t know how to code, and that programmatic animation and rich UI coding is no easy task. Unless someone comes up with a unified toolset that will give these designers the same ability to produce timeline and tweened animations, in-app vector graphic manipulation, multi-channel sound integration and nested movieclip objects in HTML5 with the same ease currently being accomplished in Flash Pro, don’t expect Flash to disappear anytime soon.

Interestingly, as Adobe CTO Kevin Lynch explains, it looks like that someone is going to be Adobe. Remember: Adobe is in the business of selling tools. They don’t make money directly with Flash itself; they make money off the tools that create Flash content. If HTML5 is where the future is headed, then that’s simply where Adobe will go.

The HTML5 video tag: will it be the final nail in Flash’s coffin?

One of the upcoming features of HTML5 which is touted to be a Flash killer is the new tag. Pundits say that Flash will die now that people will be able to natively play videos on their browsers without having to install plugins. This is great for the open web, but there’s a big problem that has brought this feature to a standstill: browser vendors cannot agree on which codec the video tag will support.

Firefox, Opera and Chrome support the open and royalty-free Ogg Theora/On2 VP3 codec, while Safari, Internet Explorer 9 and again, Chrome supports the newer H.264 which needs to be licensed. Here’s the big problem: although Ogg Theora is free, it’s not as efficient as H.264; Google’s Chris DiBona stated that if YouTube were to use Theora as its codec, it would take up most of the available bandwidth of the internet. On the other hand, Mozilla has flat-out refused to license and use the H.264 codec because it would violate the principles of free software and would become the GIF patent problem all over again. Because of this disagreement on which video format to use, HTML5 has once again brought us to same the problem in the 90’s where websites would serve videos in various incompatible formats like Real Media, ASF, WMV, DivX, Quicktime and so on. This is the exact same environmental condition on which made Flash Video took off in the first place: Flash Video simply worked hassle-free on just about every browser out there.

Now that we have established that the HTML5 video tag won’t get anywhere unless vendors can agree on a codec, do note that flash video can also be used in ways that can’t be easily achieved in HTML5 yet like:

• video conferencing (voice and video)
• live audio/video recording
• video rotation and usage as a surface on a 3D object
• overlaying dynamic objects over the video like subtitles, closed captions, or video game characters
• using multiple videos overlayed on background images and stitched seamlessly together to make animated virtual persons or what have you

Games, games, games!

Aside from video, websites, interactive CD/DVD-ROMs and kiosks, one of Flash’s other big guns is games. Consider this: Sony has sold 33.5 million Playstation 3 units, Microsoft moved 40 million X-Box 360 units and Nintendo 70.93 million with the Wii. Farmville alone has 82.4 million active users. If you think of all the Flash games out there and the number of people playing them, then Flash is now actually one of the biggest gaming platforms in the world!

That’s all well and good for browser gaming, but now, with the arrival of the HTML5 canvas element on the scene, game developers can now do the same things in HTML5 that Flash games are doing, right? After all, with HTML5 we can now do all sorts of neat stuff like this sweet space shooter game and even run ID Software’s classic Quake II 3D game! With this in mind, DHTML will supplant Flash as the medium for creating casual browser games, surely?

Well, not just yet. Flash has so many things going for it right now that can’t be easily replicated in HTML5:

• Byte-level preloading. Preloaders are important so that users know there is progress happening while your game is in a loading state. HTML5 only does this on a per object loaded basis and not with byte-level accuracy which provides better feedback for waiting users.
• Timeline animation and tweening: this is one of Flash’s biggest assets for game developers. Sprite & background animation has never been so easy!
• You can easily roll out your Flash games in convenient single-file SWF packages which you can then distribute to various game portals that will license the game from you or maybe publish it as an AIR file for sale on the Adobe AIR Marketplace or even get ’em featured on Valve’s Steam!
• Multi-touch and gesture support which can be pretty cool for certain games and applications
• Reading of raw webcam pixel data which will give you the ability to do something like Sony’s EyeToy
• Peer to peer networking – I’m really looking forward to this for multi-player Flash games.
• True, there are Flash decompilers out there, but viewing an HTML5 game’s sourcecode in a browser is so much easier than with Flash SWFs. Moreover, even if you say Javascript can be obfuscated to prevent sourcecode stealing, you can apply that same obfuscation technique to your SWF too, so Flash still wins in this department.
• Regarding Steve & other HTML5 zealots’ arguments that Flash games aren’t made for touchscreen devices and that mouseOver events wouldn’t work: well, JavaScript faces the exact same challenges anyway. What’s the difference? Flash developers can simply retrofit their games to work on touch devices so this isn’t really a problem.
• For those who are complaining about cost as a barrier to entry on developing for the Flash platform, for coders, there are actually free and open source tools that can be used to build quality SWFs today: Sun’s JDK, the Free & Open source FlashDevelop IDE (Microsoft .NET 2.0 required) and Adobe’s Open Source Flex SDK.
• Speed speed speed: check out these particle demo benchmarks. AVM2 ActionScript 3 Flash is so much faster than current Javascript implementations.

HTML5 is here, but not quite here yet. When is it going to finally arrive?

Realize this: WHATWG, the standards group steering and dictating HTML5’s spec moves so slow that it took roughly 6 years to get to where it is today (essentially a fraction of what Flash MX could do back in 2002). Also, assuming IE6 finally dies by then (doubtful), wider-spread adoption of HTML5 by manufacturers isn’t expected ’til 2012. What’s worse, the HTML5 spec isn’t even going to be finalized until 2022! That time frame gives Flash ample time to brush up the edges that other find to be rough.

Finally, HTML5 is just as bad, if not worse than Flash.

Regarding slow and bloated Flash content, the problem is not the platform itself, but with authors who don’t know how to or simply don’t optimize content. If Flash content is developed well, there should be little to no problem with the performance hit systems will take. With every Tom, Dick & Harry website going AJAX right now, a lot of sites simply can’t be viewed efficiently by low-spec machines anymore. When surfing the web on a 400MHz OLPC XO-1 laptop (first-hand experience), certain sites with Javascript turned on like Facebook is just become plain unusable. Gone are the days when you could surf the net with a Pentium 166MMX on a dial-up connection.

Prepare for a new breed of obnoxious Javascript web ads to replace those obnoxious Flash ads once HTML5 gains traction. At least with Flash ads, you can simply use Flashblock or ClickToFlash to avoid them. As more people start using Ad blockers, expect ad companies to use more and more of these floating Javascript/CSS ads that irritatingly hijack and cover webpages you’re trying to read. also, if the page you’re viewing itself is heavily laden with Javascript code, how then are automated ad-blocking solutions going to block these ads if the content they serve lie on white-listed servers?

In closing, what do I really think about HTML5 as a Flash developer?

Well I think HTML5 is great and yes, it is the future. I don’t see it replacing Flash anytime soon though as there are too many issues holding it back and there are things going for Flash that it cannot compete with. However, unless content creators learn to optimize even on HTML5 or create mobile/lite version of their websites, I see a dystopian future where low-spec mobile devices (which is where the net is headed) will have to return to the MHz arms race in order to view the most mundane of web content. Moore’s law is not going where it should: instead of making CPUs run faster and faster, they should make CPU speeds run at “just acceptable” levels and just make them cheaper with each iteration. (Mom and Dad don’t need 3GHz machines just to use Office or surf the web!) All this MHz hungry app vs. MHz escalation will lead to is just higher power consumption, overheating and shorter battery lifespans. It’s bad for you, me the entire environment and the principles of ICT4D.

HTML5 proponents, be careful what you wish for. You might just get it.