For over ten years now (and think about what a time span that is in Internet time!) Flash has been the primary platform for developing highly interactive web content and applications. Flash delivers things that were plainly impossible otherwise: animation, perfect support for mouse input, vector graphics, video, streaming; and all of that could be developed in a single, intuitive, and widely adopted development environment that enables a huge community of designers and developers to shine. Without much of a doubt, the Web would have been a duller, less inspiring, and less useful place. When Silverlight was announced, its main proposition was to be able to do the same kind of things that Flash delivers with full leverage of your skills as a .NET developer. In whole, Silverlight was a reverence to the success of Flash.
It’s a commonplace that Flash is in trouble. It’s not only that Apple is aggressively banning it from their mobile platforms – a lot of its feature set that has been unique to Flash is now being covered by HTML5. With the recent improvements in the rendering capabilities – vectors, rotations, animations – and the upcoming codecs for streaming video playback, there is hardly and more reason to use Flash. Embedding a Flash part into a web site is now considered outdated; it limits the reach of the site, adds a second technology to your skill matrix, adds friction to the process of production. A lot of the use cases for the technology just evaporate.
Of course, the same holds true for Silverlight. It is time to unite it with its anchestors on the graveyard of deas MS web technologies – ActiveX, ASP, the DNA architecture? I’d say it depends.
Let’s take a look at where the differences lie between an HTML5-based application, an RIA application that runs in Flash or Silverlight. In theory, there aren’t that many.
The application is not installed on the client prior to use. The runtime environment is on the client. It is an environemt with limited, and not always known, abilities. Access to local resources is not possible, or heavily restricted and managed.
In both models, you have a markup language that defines the content. There are visual tools to define that content. Content and style are largely separated into different compartments so that domain experts can modify them independently. Code is used to add behavior. The content can heavily be modified by code. In order to retrieve resources that are not available on the client, the application can reach out to servers in the cloud, and process that data in its own runtime.
Of course there are differences. HTML applications do not have a defined runtime environment – they need to cope with more uncertainty about the browser they run in. Script may be disabled. There is no access to external resources. The technologies used by the app are separate; cohesion is not a framework feature, it is something that developers need to provide.
RIA applications on the other hand have a more defined runtime environment, a coherent framework, and some more access to local resources like disk space, the microphone, or the printer. On the down side, there is a problem with reach – the correct version of the runtime plug-in needs to be installed, and it may altogether be unavailable for an OS or form factor (especially if vendors start acting as a format police corps).
For a wide range of use cases, both an HTML5 and a RIA application are a viable solution. But the specific challenges of the platforms influence the price that you have to pay to get your solution to work. When the framework has more to offer, there’s less for you to write. On the Silverlight platform, we can argue if we prefer MVP or MVVM, a pure DI framework like Unity, or MEF, and if we like to talk to servers using SOAP, POX, or raw TCP. This is a level of design opportunities for larger applications that HTML5 won’t offer for quite a time.
I’m trying to predict the future now. And that’s only a few days after finishing The Black Swan. At least I may add that I’m probably over-confident because I’ve been right before, and biased because my own stakes lie within the RIA field.
The areas where HTML or RIA applications are going to be used are defined by complexity. Right now (so pre-HTML5), one may draw a graph that weights complexity against the usage of a type of application (HTML, RIA, native):
HTML applicatioms will be able to take a significant bite out of what has been the domain of RIAs. But on the other hand, we’re going to see that RIAs have quite a significant piece of the cake to take: where you needed to write a native desktop application, an RIA will often be the weapon of choice. If you do not need to have really unlimited access to the client machine, why would you need to perform a heavy-weight installation? I’d guess you won’t run an installer that often any more.
The second use case for Flash and Silverlight style applications are mobile devices. For the upcoming Windows 7 Mobile platform, Silverlight is going to be the one and only application format. It’s likewise on Android: as a Silverlight developer, you’ll find yourself extremely familiar in the structure of applications and the style of programming (except that Java always feels to me like C# with the handbrake on). And it makes sense: a phone is a runtime enviroment much like a browser plug-in. It’s a specific, defined platform, and you have access to local resources in a controlled way; the reach of HTML does not play any role here.
And in the long run, I’d think that the differences between HTML and RIA style of applications disappear further – and the direction will be that the browser becomes more of a platform that the Flash or Silverlight runtime environment is right now. With a more coherent programming model for content, style, and code; with the ability to discover and use local resources, great network access, and support for multiple programming languages.
If you’re an open-minded Silverlight developer today, you won’t have much of a problem in that environment.