In the last year, Microsoft has significantly backed off of their Silverlight strategy for Web developers. Even worse, Adobe has announced that they are no longer developing mobile Flash (although partners may continue to do so); combined with the failure of Flash to achieve “critical mass” levels of penetration in mobile, it looks like at best you need a split mobile-desktop Flash strategy, and at worst, you will not have your Flash content appear on many mobile devices at all. The cause of this chaos is HTML5, and at the same time, HTML5 is the replacement for these technologies if you are ready to move on. Here are five significant tasks that developers do with Flash and Silverlight, and what your HTML5 alternatives are.


Multimedia is one of the most important things that developers use Flash and Silverlight for. Indeed, once you take YouTube into account, Flash’s use on the Web is overwhelmingly for video! Luckily, this is one of the things that HTML5 has gotten a handle on. HTML introduces two new tags, <audio> and <video>, for working with multimedia. While it is true that HTML5 has not settled on a particular codec for video at this point, it is possible to specify multiple sources of video content, so that you can encode the same video into enough codecs to have your bases covered. Ideal? No, but it is still a lot better than either handing off your content to a video site like YouTube or trying to craft your own video player.


Another reason folks use Flash and Silverlight is because they handle graphics well. Now, HTML has had various vector graphics systems in the past, and the current SVG standard is now well supported. But HTML5’s <canvas> tag isn’t for vector graphics, it is for bitmap graphics. Manipulating bitmap graphics is a task that both Flash and Silverlight do well, and before HTML5, Web developers could not do it without a plugin. With <canvas> a whole slew of possible games and applications open up for developers.

Input widget improvements

Working with the combination of HTML, CSS, and JavaScript to create controls that replicate desktop applications is a mess. Luckily, HTML5 has made improvements all around to the various widgets for input that allow for them to be used much more like desktop controls do, so you will find yourself reaching for Flash and Silverlight less often for this kind of need. For example, the “type” attribute on the <input>tag allows you to tell the browser what kind of data is going into a text field (such as date information), which in turn lets the browser do a better job of presenting the widget to the user. In addition, there is a <menu> element that lets you create menus, toolbars, and context menus, all of which add up to a very interactive experience with minimal work by the developer.

Asynchronous operations

The asynchronous processing model is critical to application development, because it allows you to do things like do heavy-duty processing in the background and not lock up the user interface, but then update the UI when the processing is done. HTML5 addresses this need with the Web Workers specification. While Web Workers is not as well-supported as some of the other items presented here, expect for them to be much more useful in the next year or so. Why? Because the major browser hold up on Web Workers is Internet Explorer, and the IE10 preview 2 includes it. Web Workers will allow you to do the kinds of client-CPU-intensive tasks that are currently realistic with desktop applications of through Flash and Silverlight.


The WebSocket specification defines two-way communications between the browser and a host. This has always been a major shortcoming of the HTML + HTTP combination, and developers have tried to imitate round-trip communications in a variety of different ways. WebSocket actually piggybacks on top of HTTP, so you won’t see the firewalls blocking it like you would with an entirely different protocol or port scheme. Like Web Workers, the WebSocket spec is still evolving and support is weak, but that is expected to change quickly; IE10 will support it, joining Firefox and Chrome, which means that within a year you can expect a high level of compatibility with WebSocket.