Leadership

How to replace Flash and Silverlight with HTML5

Justin James discusses the five main areas where HTML5 can provide alternatives to both Flash and Silverlight web development strategies.

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.

Video/audio

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.

Graphics

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 which 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.

Communications

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.

About

Justin James is the Lead Architect for Conigent.

13 comments
Slayer_
Slayer_

How do you code live and interactive animations in HTML5? Can you build entire games in HTML5, cause people have in Flash.

sandonk
sandonk

I have to disagree with the notion that the SVG standard is now well supported, or just about any suggestion that it's ready to take over for Flash's vector graphics. I recently looked into the maturity of SVG, and was very disappointed to find that many of the specs -- esp. with regard to animation/transformations, for which SVG/SMIL comes with extensive support for by definition -- have not yet been embraced. And of the standards that [i]have[/i] been embraced, many are not done so uniformly cross-browser. Also, one of the ways to evaluate the viability of SVG is whether it can be used as a cross-platform media/animation data format. But you'd be hard-pressed to find one decent, out-of-the-box SVG rendering library for any platform. And if you wanted to phase in SVG-based graphic or animated content say inside a legacy Flash-based client well, that platform too has only very sluggish open source libraries available for rendering SVGs. This is not even getting into the shortcomings with the available tool-chain for authoring SVGs, and what many shops need: conversion processes for existing Flash-based assets. Adobes Edge previews suggest that they are going the route of using [b]Javascript[/b] to manipulate SVGs, instead of encapsulating animation/transform data in the form of xml inside the SVG itself. This might be OK for the web and will certainly fare better right now with the weak SVG support browsers currently have but it doesn't solve how we might be able to efficiently deliver dynamic content with a vector-based animation format, say, inside a native iOS app. Canvas beats the snot out of SVG in performance, so that's where the focus has been in HTML5 game dev. I would love to see a sign that the browser and mobile platforms are starting to take SVG seriously. Until then I just don't see any ROI in trying to switch to SVG.

vasile_sm
vasile_sm

CLOUD COMPUTING Now you can really discuss this. Not everything has to be done by small browsers on mobile devices, processing in the cloud could be a solution, at least for them.

eruiz
eruiz

I agree with Edgard that there are applications that are most suitable for a pc or server and other applications that are for web. i remember that many years ago I have to develop a telecommunication network design application and i proposed tha have a mix of pc and server based solution, instead the users, the sistem engineers team heard about the web and html as the new way so they encourage me to try to put most of the user interface, and the bussines logic to a web server. as you can imagine finally it doesn??t work (even ESRI and open source friends has amazing products to do something similar) and finally it was developed as initially was thougth. The "n"- layer paradigm (...technique or whatever you wanna to call it), of "engineering system", helps and states that you have to focus the user of your system and identifies what functions should be used on each device you wanna use. I can't imagine how a 70,000 towns nationwide network can be visualized in a small factor screen of a mobile phone (or a tablet) in an usefull way using the same bussiness components used for an appropiate 4 cores procesor, workstation with 2 - 24'' screens, and even that the user expect the same performance and the same tasks in both kind of terminals. Actually, according the technology development, If a user choose a mobile device is mainly for the "mobile" meaning, so as the technology improve the processing capability of such terminals, the "web part" of the applications (server and device) should be enough ligth to reduce the data interchange (remember the prices for mobile phones data rates are set to mbps transmitted in a month basis, not in a bandwidth basis, as is must be) or constrained to the best case of local wifi bandwidth (peak rate of 10 - 54 mbps shared between all the users attached to the acceso point). Best regards, Elias

EdgarHarris
EdgarHarris

Instead of pretending like the browser is suitable for applications we could just make native client apps that are powered by servers on the internet. Developing applications in Javascript is literally 5-10 times more expensive than developing applications using real developer tools, e.g. Visual Studio with C#. For the cost of developing a single bug free HTML5 client app you could develop a PC Desktop client app, a iOS client app, and an Android client app, each with a user experience tailored to their device. Let's stop pretending like the browser is suitable for application development. If the w3c was really interested in making HTML5 a viable development platform, they would have made user controls first class citizens. They would have added a binding engine to HTML5, and they would have given us a better language to develop in than Javascript. None of those things happened, and none of those things will ever happen. Instead all we have gotten are half measures from the w3c, and quite frankly that isn't good enough.

Justin James
Justin James

Check out the Adobe Edge beta for an example. Using it was similar to working in Flash, and it uses only JavaScript, CSS, and HTML5 to do animations and such. It's not nearly "done" but as a proof of concept it's convincing. J.Ja

belli_bettens
belli_bettens

Doesn't matter where the processing takes place, in the end you use HTML(5) as the view. Native application can also use the cloud as their 'processing source'

Justin James
Justin James

I used to agree 100% with your view, but now I don't. There are two very powerful reasons why I've changed my mind. First and foremost, while the client side of Web development is still lacking in many ways, a variety of toolkits (primarily jQuery) have emerged that soak up enough of the pain to make things usable for the developer. A few years ago, writing Web apps with desktop-like capabilities was about as much work as writing Windows apps was pre-VB, pre-Delphi. If you don't remember those days... well I do, and it wasn't pretty! jQueryand the HTML5 technologies are basically the VB 3 of the Web. Perfect? NO! But they are "good enough" to let the average developer do what they need to do. Remember, the native development that looks so easy and smooth today was a trainwreck as recently as 15 years ago. In 15 years, we'll be looking at today's Web client side stuff the same way, and telling our kids about how bad we had it. :) The other thing that's changed is the explosion of mobile devices. The native model is quickly losing ground, and we need cross platform solutions. As you say, in many (most, maybe?) cases, the best bet is to do everything with a Web service and just use a thin shell of a native app over it. In fact, basically the article I wrote last week in the "Software Engineering" section, and earlier today we posted my article outlining how to architect it. But, for those situations where a zero-footprint or zero-install is needed (and there are lots of those situations!), there really is no alternative to HTML at this point. So, we can either roll with the punches and wait for what we have to mature, or we can pretend it isn't happening and suffer the consequences. J.Ja

EdgarHarris
EdgarHarris

I have to confess I have very limited experience with the pre .Net world of development. I've only been doing this for 8 years, and the only MFC application I did was for Windows CE, and yes it was incredibly painful. I think if you're working on an app that needs a zero-footprint or zero-install then you're right, and HTML5 is the only real option. I also think that there are lot of applications that don't have that requirement. However a good portion of these applications target the browser, because it's the cool thing to do. There are number of apps that I've worked on that target the browser even though this doesn't solve a single business problem for us or our customers. In fact right now there are people I'm working with who are pushing to move to HTML5 because "it's the future". They've gotten so caught up in the HTML5 hype train that they aren't even asking how a move to HTML5 benefits our product. Lastly you say that the native model is quickly losing ground. I disagree, and in fact I think the advent of mobile devices is actually accelerating a trend back to native apps. Cross platform development doesn't make a whole lot of sense if you want to target both mobile devices that use touch screens and Desktop devices that use the mouse and keyboard. You need different UI's that target these different input models, so there is no point in trying to write a one size fits all client. In fact there is a lot of evidence that browser apps are losing ground to native client apps. See wired magazine's article: The Web is Dead Long Live the Internet. http://www.wired.com/magazine/2010/08/ff_webrip/all/1

Slayer_
Slayer_

Not just full Applications, then the average windows 7 user has about 10,000 apps, not including those that run using rundll.

belli_bettens
belli_bettens

regarding your article: a lot can change in 1.5 years ;-) They talk about apps but they don't necessarily make a distinction between web- or native apps. They just talk about the internet as a collection of websites vs. apps using the internet. That's a different thing as what we are talking about. For the end user it's not really a difference whether they use a native or web app, as long as it works and looks the way they're used too it. The real advantage is for the developer who doesn't need to write and distribute many different versions of the same application.

Justin James
Justin James

In my "day job", I get to wear a lot of hats. One of them is "system administrator". I promise you, sys admins love Web apps (one server to manage, and it uses standard, consistent technologies like IIS or Apache, SQL Server or MySQL, etc.). Troubleshooting processes are the same across the board, so is maintenance, etc. Compared to native apps, Web apps are a joy for them, and if you look at the business world, Web apps have completely blown native apps out of the water. For consumers, though, these issues are less of a concern, and ONLY in the mobile app model at that. I agree that doing a different UI per form factor makes sense (note: there is NOTHING stopping you from using a different Web site for different form factors...). You'll note that the typical consumer has almost no native apps installed on a PC, and that's been the case for a while. J.Ja

Editor's Picks