blake - Thursday, March 18th, 2010
There’s been a lot of talk lately about HTML5 and how it will completely change the landscape of the web. Folks as high up on the technology food chain as Steve Jobs tout it as the ultimate replacement for Flash. So, in an effort to be a good programmer, I spent some time learning HTML5 (specifically the canvas component) to compare capabilities. I can emphatically say that HTML5 will not be a Flash killer, with the only possible exception being video, and here are the reasons why:
Just try to get a programmer to drop OOP
Flash is run through the ActionScript language, and AS3, the version of ActionScript that’s been around for almost four years, is object oriented. For those not familiar with OOP, it’s by far the most preferred method of coding for experienced software engineers, most of who consider non-OOP languages archaic (probably the nicest thing they would say).
On the other hand, JavaScript, which runs the HTML5 canvas component, is not a fully object oriented language, though in some ways it attempts to mimic OOP. Creating a fully functional Rich Internet Application (other than basic information aggregators) in JavaScript is frustrating at best, and down right futile at worst. Any way you slice it, moving from AS3 to JavaScript is a step down in capability, and no experienced programmer will rush to do it.
I have to manually support different browsers?
A Flash application will run on any operating system in any browser. The only possible issue is the display of system fonts, which can easily be averted by embedding fonts in the application. HTML5, though, brings with it all the same browser compatibility problems that currently plague web designers. A HTML5 application playing sound or video will have to support every codec used by all major browsers. So, instead of having one mp3 for every sound in Flash application, the developer will have to make a mp3, wav, and ogg for every sound that needs to be played and write code to test the browsers supported codecs.
The same goes for video. Websites that want to support video playback will have to encode all their videos in both the h.264 and Ogg Theora codecs. Imagine a site with a video repository the size of Hulu’s deciding to go through every single one of their thousands of h.264 videos and re-encoding them for Ogg, especially when their Flash video player works just fine for them already. YouTube recently launched an HTML5 player, but decided not to support Ogg, so the only browsers it can be viewed in are Safari and Chrome. Beyond the codec issue, the HTML5 video component actually does work very well, and I suspect that we’ll begin to see it used more often.
I’ve also noticed some screen redrawing issues that vary between browsers. When redrawing large bitmaps on the canvas, the area would flicker sporadically, as if the browser couldn’t catch up to the redraw calls. Once again, this is not an issue in Flash, since it takes care of redrawing the stage automatically.
Code obfuscation, anyone?
Code obfuscation is a process by which interpreted code, such as JavaScript, is modified to make it difficult to read without modifying the functionality of the application. It’s used to keep code that has to be public from being stolen. With JavaScript, you have no choice but to make the source code public and anyone with a moderate knowledge of web browsers can easily steal it, so obfuscation is a fairly common practice.
To help illustrate the current issues with code obfuscation and the canvas component, here’s a little Pong game I wrote in HTML5. You’ll only be able to play it if you have a capable browser, such as Firefox, Chrome or Safari.
I attempted to use every online JavaScript obfuscation tool with the source code for that Pong game (only 280 lines long), but not one of them returned me code that worked. I suspect that’s because they’re not able to handle HTML5 calls yet, or perhaps they don’t really work that well in the first place. For the sake of argument, let’s assume that you, a developer, have successfully obfuscated your JavaScript code and have put it online. An inventive hacker could find out which tool you used and reverse the process to get, at least, something close to the original source (encoded variable names might not be restored). While Flash has it’s own obfuscation built in, and there are many decompilers for it, it’s a semi-interpreted language, so deconstructed applications reveal only snippets of the original source.
While I’m all for open source, site security dictates that some code has to be as close to impossible to hack as humanly possible (no code is 100% hack proof). Most secure functions on websites are done on the server to keep hackers from reaching it through the browser, but with Rich Internet Applications that deal with secure information, there has to be an intermediary point where the application sends and receives sensitive data. It’s much easier for a hacker to retrieve that procedure through JavaScript, obfuscated or not, than from a plugin.
Flash to the rescue
The idea behind HTML5 is a solid one. The kind of functionality that Flash delivers is ultimately something that should move out of a plugin and in to the browser, but this isn’t an easy change to make. The main roadblock is the core difference between web and application programming. HTML has never been more than a document format, and through the last fifteen years of mass marketed internet, developers have tacked on external languages to give it greater functionality. In the last few years, Flash has become the most used way to bring native application functionality to an HTML page, and it was able to do it because AS3 is a language of substantial depth, based on OOP principles.
Because of this, I think the best hope for HTML5 is for Adobe to add an “Export To HTML5″ feature to the Flash IDE and Flex SDK. I suspect talk of it is already floating around their headquarters, because, despite what someone said, they are most definitely not lazy.