Practical ASP.NET

Platforms Question: Silverlight and ASP.NET

Peter Vogel reviews the decision that organizations will have to make in choosing between Silverlight and ASP.NET.

• By Peter Vogel
• 01/20/2011

In the February issue of Visual Studio Magazine, I wrote the Web and RIA Development capsule of the .NET Survival Guide feature. I opened with comment that "Microsoft's latest announcements make it clear that, when it comes to delivering applications over the Web, the choices for the .NET developer are ASP.NET and ASP.NET MVC. Silverlight may have a future in mobile development, but it's no longer a primary platform for the Web." This column is about unpacking those sentences about Silverlight, ASP.NET and ASP.NET MVC.

I divide the world into two kinds of applications: those for users tethered to the organization and those for users that aren't. Obviously, "tethered users" include employees with desktop computers within the organization, laptops used by road warriors, and (probably) computers used at home by employees. Less obviously, it also includes users who are "coerced" into working with the organization: customers, partners, vendors and others who have to work with the organization and, as a result, have to meet the organization's software demands.

With client after client, I find organizations building applications for tethered users and not considering Silverlight. In my mind, Silverlight (as of version 3) has supplanted both Windows Forms and WPF as the premier tool for delivering what used to be referred to as desktop, line of business, or intranet applications.

If you want the richest user interface while delivering functionality in the shortest possible time, you should be looking at Silverlight. I'm a big fan of service-oriented architectures (I'm the current author of Learning Tree International's course on designing SOAs, for instance) and, it seems to me, that Silverlight has been designed with service integration in mind. Furthermore, Silverlight is designed to let you deliver those applications through the browser and a network connection -- and, these days, everyone has a browser and an Internet connection. Users will require the Silverlight runtime but, as tethered users, you can either pre-install the runtime or users will eat the cost of installing it themselves. It's not an onerous burden.

There are only two significant strikes against using Silverlight with tethered users. I'll come back to them.

But what about "untethered" users? These include people who are not part of your organization, vendors/customers/partners on whom you can't impose software (e.g. users who must be enticed to use your software). As before, you can guarantee two things with these users: they will have a browser and an Internet connection. The only way that you'll reach all of these users is through HTML (or HTML + JavaScript). These are what are still referred to as "Web" applications.

And I do understand that Silverlight reaches most of those people -- even a very large percentage of those people. But my guess is that when management says, "We want to reach everyone," they really do mean everyone. And the richer user interface and higher productivity of Silverlight is not going to be compelling against the fact that Silverlight only reaches almost everyone. Linux is out. Any browser other than IE, FireFox, Safari and Chrome (mostly) is iffy. Microsoft has recognized that there are browsers Silverlight won't ever support (e.g. mobile devices). As a result, Silverlight will never have the reach of HTML + JavaScript.

And please don't think that if you build a great enough UI untethered users will abandon their computing platform of choice, even momentarily, to use your app. If your organization wants everyone then your development tools is ASP.NET and ASP.NET MVC. I'm not denying that organizations are building applications for tethered users using ASP.NET when they don't need to -- but people do lots of silly things.

Which brings me back to the two strikes against Silverlight that might cause an organization to not choose Silverlight even for applications targeted at tethered users. The first is that Silverlight won't (and won't ever) work on many (most?) mobile devices. A separate strategy based around the answer to two questions is required here. The first question is how many of the organization's applications will need to be delivered to mobile devices. The second is which mobile devices will be supported.

Most organizations are not yet imposing/buying mobile devices for their tethered users (I think that buying your mobile device is considered a "personal" choice). And few organizations will have the resources to support all the native mobile development platforms. So, if the answer to both of those questions is either "all," or even "a lot," then ASP.NET/ASP.NET MVC might be the best strategy even for tethered users even in this area.

As the second question suggests, the issue here is fragmentation. Even in non-mobile devices, there may be tethered users that aren't using the same platform as most tethered users. For various reasons, the organization may not be willing change that. For instance, an organization's publishing department may be using Macintoshes while the rest of the organization is using Windows. As Microsoft has indicated recently, Silverlight developers should consider developing separate user interfaces for different platforms. When building applications with a fragmented user base, HTML + JavaScript might be a more economical choice even with a "less-rich" user interface and lowered productivity.

I think that most organizations are willing to support two toolsets for these two sets of users, especially because they can standardize on one toolset for the backend by using services. Sadly for Silverlight adoption, if an organization wants one toolset and has both sets of users, then their best choice is ASP.NET. But I suspect that doesn't represent a lot of organizations.