HTML5 assault on Adobe Flash heats up with ClickToFlash

El asalto de HTML5 a Adobe Flash se calienta con ClickToFlash

ClickToFlash allows Safari users to isolate Flash content on the web so that it only plays when they choose to allow it. Flash content is replaced with a bounding box that enables the user to ignore the item (such as with ads) or to click the placeholder to activate Flash playback as desired.

Additionally, the plugin can convert requests for YouTube Flash videos into requests for higher quality H.264 videos, allowing desktop users to bypass Flash the same way the iPhone does, and simply play any YouTube videos using the browser's own built-in HTML5 support for direct H.264 playback.

The examples below compare the same HD clip served by YouTube, first rendered using Flash with the standard grey YouTube playback controls, and then presented in H.264 using ClickToFlash to request the non-Flash version from Google. The native HTML5 version results in Safari using its own native QuickTime X playback controls rather than those created by Google using Flash. During playback, Safari's native black playback bar disappears; using the ClickToFlash plugin, the user can also present H.264 videos using full screen playback.

In addition to offering better quality video and more functional and accurate playback controls for smoothly navigating through the video clip, ClickToFlash's direct playback using HTML5 prevents the Flash plugin from ever engaging and consuming CPU cycles and notebook battery life. Outside of YouTube, this means that loading web pages won't max out your processor just to animate Flash ads in the background. Any essential Flash elements, such as navigation components, can be activated by clicking on the placeholder created by ClickToFlash as desired.

In the example below, Safari with ClickToFlash does not load Flash content on the New York Times site by default, but will load individual items at the user's request. On the iPhone, no Flash content is ever loaded nor can be. Most ad networks using Flash now sense the iPhone's user agent and supply alternative, non-Flash ad banners. As more users opt out of Flash, the ad market will follow, just as it has accommodated the iPhone. Videos will also move to H.264 in order to support modern browsers that don't need Flash just to present video clips.

"One of ClickToFlash's primary goals is to eliminate as much Flash from the web as possible, allowing users to choose only the Flash they want to see," the plugin's development website says. The group asks for help in adding direct video support for other sites that currently use Flash to facilitate video playback.

As support for H.264 video delivered by simple HTML5 video tags erodes the primary demand for Flash on the web, and as web developers become familiar with using HTML5's new Canvas feature to perform sophisticated drawing effects within web pages without using a plugin such as Flash or Silverlight, many observers report that Adobe will face an uphill battle to continue to push closed Flash development as an alternative to using open web standards, particularly as new initiatives such as WebGL hardware accelerated 3D begin to gain traction.

On page 2 of 3: Adobe's mobile strategy for Flash, creating iPhone apps.

Adobe's mobile strategy for Flash

While ClickToFlash works to kill Flash on the desktop, the existing battle between Adobe's Flash and HTML5 has been waged squarely in the mobile realm. Apple introduced the iPhone without support for either the desktop version of Flash or Flash Lite, a subset of Flash aimed at smartphone devices. As Apple became increasingly adamant in opposing Flash on the iPhone, Adobe reported that it had a Flash Player for the iPhone under wraps and nearing completion, and suggested that Apple was even involved in working on the project.

That changed with the announcement this week that Adobe would be releasing a new version of Flash Player 10 for other mobile platforms over the next year, with an initial public beta for Windows Mobile and Palm's WebOS by the end of the year, followed by betas for Android, Symbian, and RIM's BlackBerry OS sometime in 2010. Missing from those announcements was the hottest mobile device on the market: the iPhone/iPod touch.

(Updated since original publication to note that RIM is working with the Open Screen Project; Adobe says "The collaboration is expected to bring the full Flash Player browser runtime to BlackBerry smartphones.")

Adobe addressed iPhone development with the announcement that its upcoming CS5 Flash development tools would enable the production of native iPhone apps. The resulting applications are not Flash, and this does nothing to enable Flash playback on the iPhone, either within standalone apps or embedded in web pages.

Creating iPhone apps using Flash CS5

Flash "applications" replace open and standard web content created using HTML, CSS, and JavaScript with Adobe's proprietary .swf, a closed binary file that wraps up web content files (such as graphics and movies) with the company's own variant of ECMAScript (JavaScript), called ActionScript. In CS5, the Flash development tools will allow new Flash projects to be exported as standard iPhone apps rather than .swf files.

Adobe is doing this using LLVM (Low Level Virtual Machine), an open source compiler technology supported by Apple and used in its Xcode Mac and iPhone development tools. The next version of Adobe's Flash development app will simply compile Flash ActionScript into native iPhone code, much as existing tools already allow iPhone developers to write their code using Java, Scheme, or other languages, and then compile the code into C or Objective-C as a native iPhone app.

The iPhone is designed not to support any alternative languages via any sort of virtual machine, which prevents it from running "raw" Java, Flash, .Net, Silverlight, or anything else apart from its native C/Objective-C compiled to the ARM processor. This is enforced in the terms of Apple's SDK agreement. There is however no restriction against compiling any existing code into native C/Objective-C and creating an iPhone app from it.

On page 3 of 3: Porting the many faces of Flash to mobiles.

Porting Flash to the mobile

Existing Flash projects will require some additional work to get them on the iPhone; Adobe notes the iPhone's 320x480 resolution is not the target resolution of most Flash apps aimed at web users, and that touch navigation will not work with content designed around the use of a precise mouse pointer.

"Certain behaviors that you may often employ in desktop application development will not necessarily apply to the iPhone," writes Adobe spokesman Aditya Bansod in a blog posting announcing the new tools. He also warns, "The iPhone is most decidedly not a desktop computer. It has very powerful and sophisticated hardware, but there is a wide spectrum of capabilities between the different generations of device, the amount of memory available, and the amount of processing power your application has at its disposal."

Adobe's Applications for iPhone FAQ further notes, "The iPhone and iPod touch have processors significantly slower than those found on most desktop PCs and Macs. Thus, content may run slower than it does when running on a desktop personal computer. However, the exact differences will depend on the specific content."

The many faces of Flash

Adobe also states that any Flash content intended for conversion to an iPhone app must use ActionScript 3.0, which debuted with Flash 9. Previous versions of Flash used ActionScript 1.0 or 2.0, which are run using an entirely different virtual machine compared to ActionScript 3.0. The desktop Flash plugin supplies two different virtual machines, one for playing existing ActionScript 1/2 bytecode, and a second for executing ActionScript 3.0.

Adobe's existing version of Flash Lite 3.0 for mobiles only supports ActionScript 2.0, which means Flash Lite can't run modern Flash 9 or 10 content. The new Flash 10 player Adobe is aiming at mobile users over the next year will only run ActionScript 3.0, which conversely means that legacy Flash content designed to work with Flash Lite won't work on new devices.

This diversity helps balloon the desktop version of Flash, which makes no effort to force the adoption of modern Flash content because it has the resources available to run legacy content using multiple virtual machines. But that doesn't translate to the mobile realm, where battery life and processing power constraints make the fat desktop Flash plugin and its pair of virtual machines unworkable.

Adobe's plans to ship a "full" mobile version of Flash 10 that only supports new 3.0 bytecode will suddenly obsolesce all existing Flash content that is more than a couple years old. That includes anything designed to work with Flash Lite, Adobe's current mobile strategy. That will force mobile Flash developers to rewrite all of their Flash code in order for their content to work with the new mobile player, undermining a key reason for wanting to use Flash in the first place: its wide installed base.

Additionally, with the iPhone consuming around half of all mobile web traffic, mobile Flash developers will have to contemplate whether it's worth it to rewrite all their existing Flash content in ActionScript 3.0 just to target the non-iPhone platforms that should be able to run Flash Player 10 by sometime over next year.

The alternative is to build HTML5 apps using standard JavaScript, which already runs on the iPhone and on other WebKit mobile browsers such as those for Nokia's Symbian, Google's Android, RIM's BlackBerry OS, and Palm's WebOS.

Such open content will not only work on the iPhone and BlackBerry, but will also run on desktop browsers including WebKit browsers such as Safari and Chrome; Mozilla's Firefox; Opera; and even Internet Explorer using Google's Chrome Frame plugin.

Daniel Eran Dilger is the author of "Snow Leopard Server (Developer Reference)," a new book from Wiley available now for pre-order at a special price from Amazon.