summaryrefslogtreecommitdiff
path: root/published/flashkiller.txt
blob: a1e6c00a12030f882b30487a84a0b7069e46da3d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
Much has been made of how HTML5 will "kill" proprietary media tools and players from Adobe Systems and Microsoft. Web advocates claim that with the much more sophisticated audio, video and animation tools in HTML 5, the web will no longer need proprietary plugins from outside vendors. 

While you'd be hard pressed to find anyone outside Microsoft or Adobe who thinks that a totally open web, where anyone can build anything without needing outside tools, is a bad thing, making that vision a reality will likely prove much more complex than even its most taciturn supporters are willing to admit.

HTML 5 is a nice dream on paper, but the practical realities of web development mean that the dream faces a serious uphill battle and even if it does end up winning, it isn't likely to happen any time soon.

There's no question that HTML 5 is a revolutionary upgrade for the language that powers the web. Much of the spec was specifically designed to plug precisely the gaps that Flash and its brethren currently fill -- like the animation API tools for the Canvas element, Local Storage, Web Workers and the audio and video tags -- promise to make Flash and Silverlight's life more difficult. 

Eventually, when browser makers fully support all that HTML 5 has to offer, it will be possible to build the powerful web apps that today require add-on technologies like Adobe Flash, Microsoft Silverlight or Sun (now Oracle) JavaFX.

However, to suggest that HTML 5 means the death of Flash or Silverlight is immanent entirely ignores several practical realities that go far beyond simple problems like browser support. 

There are other problems HTML 5 faces in its quest to replace the current crop of single-vendor tools like Flash. The spec recently received a significant blow when its creators announced that it would not specify a default codec for the video tag. 

The browser manufacturers involved in the WHAT WG, the group that is developing HTML 5, <a href="http://www.theregister.co.uk/2009/07/08/html_5_media_spec/">couldn't agree on video codec</a> so, at least for now, its not part of the official spec.

That means browsers will continue to implement the codecs and APIs ordained by their owners as they've always done, leaving developers and customers to pick a side or go to the additional cost and effort of supporting different players.

In short, HTML 5 video isn't going to kill Flash video players any time soon. YouTube and other major players in the web video world face the same conundrum that drove them to Flash-based players in the first place -- offer multiple videos based on browser configuration or use Flash for a "just works" user experience.

And don't forget that Flash is more than just a video container, it also powers much of the animation on the web. That's where the new Canvas APIs are supposed to come in -- they give designers a way to create the sort of sophisticated animation elements that Flash is often used for today. 

However, at the moment there are next to no developer tools for creating animations using Canvas. 

If you want to animate something in Flash it's a simple point and click experience. If you want to do the same for Canvas, you'll need to break out a text editor and tap into your thorough knowledge of JavaScript. To work with Canvas, designers must become programmers, a shift that most will look upon with horror.

Take away the Flash development interface and the two technologies would be competing on an even playing field, but so long as Flash makes it infinitely easier for non-programmers to create animations, don't expect those same people to be in a rush to abandon what they know.

And if the developers and designers building the web aren't making the transition to HTML 5-based solutions, don't expect Flash and Silverlight to die off any time soon.

Even Google, probably the loudest and largest HTML 5 advocate in the room, understands that without widespread developer support, Canvas and other HTML 5 tools will never make inroads against the plugins they're designed to replace.

Google vice president of engineering Vic Gundotra recently <a href="http://www.theregister.co.uk/2009/05/27/youtube_html5/">exhorted developers gathered at the company's I/O conference to use the new tools</a>, saying, "having the underlying capability in the browser is not enough." According to Gundotra, "it's up to [developers] and companies like Google to build compelling apps that build on these capabilities."

But that's exactly where the problem of browser support rears its ugly head again. From the developer standpoint, HTML 5 faces a chicken-and-egg sort of conundrum. There's currently a dearth of developer tools for working with the animation frameworks that HTML 5 offers, but at least part of the reason there's no developer tools is that the Canvas element isn't widely supported.

Adobe's John Dowdell recently addressed some of the hype around HTML 5 on his blog, writing, that while <a href="http://blogs.adobe.com/jd/2009/06/adobe_on_html5.html">HTML 5's potential looks promising</a>, "de facto capability determines what you can actually do for real audiences."

In other words, while Adobe recognizes that there's a threat to Flash lurking in HTML 5, it isn't a very big threat in today's web world. How long that will remain true is of course the real question.

If Google has anything to say about it, the answer will be not long. The company is already building with HTML 5's toolset -- the new Gmail app for the iPhone uses the HTML 5 local storage mechanism for offline mail access. 

But even when Google relies on HTML 5, the company still sometimes falls back on other tools. For example, Google Wave, the company's attempt to replace e-mail with something new, makes heavy use of HTML 5, but Wave also requires the Gears plugin for some of its functionality.

Even assuming (and this is a big assumption) that things go HTML 5's way -- new browsers support it and developers use it -- its Flash-killer days are still somewhat distant. HTML 5 still has to contend with the perpetual elephant in the room -- legacy browsers. 

It seems a forgone conclusion at this point that in the next few years HTML 5 will eventually be adopted and supported by all the major browsers, but what about today's browsers?

Google, Mozilla and Apple all aggressively push software updates to their users, but Microsoft doesn't. If the transition from IE 6 to IE 7 to IE 8 is any indication, it's going to be quite some time before using HTML 5 tools is a practical idea for major websites. 

Forget IE 6, forget IE 7, IE 8 doesn't support very much of HTML 5, which means before deploying HTML 5 becomes practical IE 8 needs to expire. It's been nearly 9 years since the release of IE 6 and it still manages to hold between 15-20 percent of the market (depending on what set of stats you want to believe).

Even being charitable and assuming IE 8's successor fully implements HTML 5 and enjoys double the adoption rate of its predecessors, it's going to be at least five years before the majority of users have a browser capable of rendering HTML 5 in all its glory.

In the mean time expect Flash and Silverlight to continue to be a necessary part of the web ecosystem.

Will HTML 5 one day make Flash, Silverlight and other plug-in technologies obsolete? Most likely, but unfortunately that day is still quite a ways off.