HTML5 & Flash Revisited

(Update Notes: This article was originally posted on TheNextWeb and has been updated. Be sure to also check out the iPhone-toting Flash co-creator Jonathan Gay’s thoughts on Steve Jobs and Flash and how Adobe Loves Choice for developers.)
—–
When Apple unveiled the iPad back in January, its glaring lack of support for the Flash browser plug-in ignited HTML5 vs. Flash discussions once more. At the heart of the debate is that Flash will become obsolete because HTML5 would duplicate much of its functionality. As a developer who actually works on the web and with the Flash platform (as opposed to critics who’ve never touched a line of Javascript and Actionscript), I’d like to point out a few things about this Mac vs. PC-ish debacle that just won’t die.
1) The Web is ruled not by developers, but by designers
What HTML5 promises to bring is the rich interactive web. Finally, developers can create the same whiz-bang object animation, tweening effects and video that have long been the domain of Flash without having to rely on a proprietary plugin. Hurrah, Flash is dead!
…right?
No. One thing anti-Flash proponents have to realize is that the web is ruled mostly by designers who have little to minimal coding skills and that UI coding + programmatic animation are no easy tasks even for most seasoned developers. Unless someone comes up with a unified toolset for HTML5 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 with the same ease accomplished in Flash Professional, 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 with Flash itself directly; 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.
Update Note:Adobe Dreamweaver CS5 now has support for HTML5 via the HTML5 Update Pack extension.
2) The HTML5 video tag: will it be the final nail in Flash’s coffin?
One of the new features in HTML5 that is touted to be a Flash killer is the new <video> element. Pundits say that Flash will die now that people will be able to natively play videos on their browsers without having to install third-party plug-ins. This is great for the open web, but there’s a very big problem that has brought this feature to a standstill: browser vendors can’t agree on which codec the video tag should support.
Firefox, Opera and Chrome support the open and royalty-free Ogg Theora/On2 VP3 codec, while Safari, Internet Explorer 9 and again, Chrome support the newer H.264 codec which needs to be licensed. Here’s the problem: although Ogg Theora is free, it’s not as efficient as H.264 and 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 refuses to license and use the H.264 codec because it would violate the principles of free software and it would become the GIF patent problem all over again. Because of the 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.
Also, note that Flash video can also be used in ways that can’t be easily achieved in HTML5 like:
-
live audio/video conferencing and recording
-
tagging and overlaying dynamic objects over video like subtitles, closed captions, etc
-
video rotation and usage as a surface on a 3D object (this one will knock your socks off!)
-
DRM encryption for protecting online content — something many television networks and studios require before they put their videos on the web.
Update Note: Google just open-sourced the On2 VP8 video codec and a consortium has formed around it as the WebM Project. Good news for the open web: this means browser vendors can now have a common video codec to agree upon and that the HTML5 <video> tag can finally move forward!
3) Games, games, games!
Aside from video, websites, interactive CD/DVD-ROMs and kiosks, one of Flash’s other big uses is for 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. If Farmville alone has 82.4 million active users and you think of all the other Flash games out there and the 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: these are two of Flash’s biggest assets for game developers. Animating sprite, background & user interface has never been so easy!
-
Multi-touch and gesture support which can be pretty cool for new games and applications
-
Processing 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. This could be a game changer because the traditional client-server model has a lot of lag issues.
-
Better content protection: true, there are Flash decompilers out there, but viewing an HTML5 game’s sourcecode and grabbing its assets is so much easier in browser HTML 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 Jobs’s & other HTML5 zealots’ FUD 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. In fact, Flash works pretty well on touch-based devices because it was originally created as a technology for tablets with touch interfaces!
-
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 Platform!
-
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 like the combo of 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. Using Flash’s AVM2 with ActionScript 3 runs so much faster than current Javascript implementations.
4) HTML5 is 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 dies soon (doubtful), widespread 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! At the pace at which Flash evolves, imagine what it would look like by then! Seriously, 2022?
5) 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 optimize content. If Flash content is developed pretty 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 can no longer be viewed efficiently by low-spec machines. 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 166 MMX on a dial-up connection. Exacerbating this problem is the fact that more and more websites require the user to browse with Javascript turned on and even worse, provide no mobile/low-bandwidth barebones alternative version of the site.
Finally, expect to see the new breed of obnoxious Javascript web ads to replace those obnoxious ones made in Flash 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 of those floating Javascript/CSS ads that irritatingly hijack and cover webpages you’re trying to read. If the page contains Javascript, how then will ad blockers tell which scripts are ads, especially if the ad content were to reside on white-listed servers?
Closing remarks
What do I think about HTML5 as a Flash developer?
Well I think HTML5 is great and yes, it is the future. I don’t see it as replacing Flash anytime soon as there are too many issues holding it back and that there are things going for Flash that HTML5 cannot compete with. Also, unless authors learn to optimize HTML5 content or create mobile/lite versions of their sites, I see a dystopian future where trying to view simple content on low-spec mobile devices (which is where computing is headed) will trigger the MHz arms race once again. It’s a vicious cycle that’s bad for the environment: Faster CPUs encourage sloppy developers who don’t optimize content, then bloated content forces users to buy faster and more power-hungry devices.
HTML5 proponents, be careful what you wish for. You might just get it.








One Response. Yay!
Sony Ericsson c902i – Mobile phone with excellent features | Download Zone
May 29th, 2010
You must be logged in to post a comment.