Skip navigation

The World Is Big Enough for Silverlight and HTML 5

Silverlight for web apps, HTML 5 for websites

A recent fight between HTML 5 and Silverlight developers in the blogosphere/Twitter-verse recently made me think about some of the mixed messages that web developers might be sending to Microsoft and other core web-technology companies.

Pandora's Box at PDC
To date, Ian Smith has one of the best "blow-by-blow" reviews of what precipitated this flame war within the development community—which he outlined in a blog post called Silverlight Shenanigans. As Ian points out, this problem actually started to surface a few months ago. It didn't, however, come to a head until a lack of coverage of Silverlight 5 (at the expense of extensive coverage of HTML 5) at PDC was coupled with a statement by Bob Muglia about Microsoft's change in strategy for Silverlight.

From here, heavily invested Silverlight developers became worried, some Silverlight zealots naturally then lashed out at HTML 5 as not being able to meet their needs, and some HTML 5 zealots, in turn, were only too quick to point out why they aren't that enthused about Silverlight.

The problem, of course (other than the fact that Microsoft is not deprecating Silverlight in the slightest), is that this would be like an argument between carpenters about which is better: a hammer or a saw.

Hammer or Saw?
For heavily invested Silverlight developers, I can understand why they would be aghast at the potential prospect of being "forced" to use HTML 5 for their applications. To many of them, I'm sure that HTML 5 really looks like a franken-tier of components and technologies that is stretched too thinly across far too many browsers that lack any semblance of homogeneity. For these web developers, the prospect of having to "drop" to a mismatched bag of different tricks, tools, and technologies to build their applications would be a huge productivity hit compared with what they're capable of with Silverlight today.

On the other hand, most site developers have spent a fair amount of time looking at Silverlight (and Flash), and found it wanting—or even undesirable for their needs. Among other things, as cool as something like Flash or Silverlight may be in terms of User Experience (UX), it comes at the cost of SEO/SEM—something most site developers can't afford to ignore. That, and while Flash still has impeccable market penetration, Silverlight just hasn't been able to reach the same level of ubiquity, despite some seriously amazing growth over the past few years.

Will the Real Web Devs Please Stand Up?
I've long maintained that that there is a huge difference between building websites and building web applications. Yes, there are some huge commonalities between both types of development—and the people who do both kinds of development call all call themselves web developers. Some web developers are also just fine moving back and forth between both types of development. But most web developers tend to focus on one kind of web development (at least for long periods of time): app development, or site development.

In other words, the silly thing about this whole HTML 5 vs. Silverlight issue is that it somehow became a question of which technology is better. Which is dumb, because both technologies are better. Meaning that, in general, Silverlight is a better technology for web apps, and HTML 5 will end up being a better option and platform for websites.
Put differently, site development tends to be heavily focused on attracting, maintaining, and converting (i.e., to sales, change of opinion, action, whatever) the widest audiences possible. Site development, therefore, places a huge amount of focus on SEO—because indexable content can help sites accomplish their goals of reaching and impacting the largest audiences possible. Rich media on these kinds of sites has traditionally been handled by Flash (and to an increasing amount by Silverlight). But each time a decision is made to add increased media (or other) capabilities, it has been juxtaposed against the potential to diminish audience, reach, or conversion.

With web applications, however, there's a totally different focus, which (typically) is primarily on functionality, capability, and the need for agility in terms of adding new features and capabilities. More importantly, though, discoverability and a focus on growing audience sizes are typically not a consideration when it comes to most line-of-business applications. Yes, these apps need to be able to be accessible from a wide variety of different hosts or platforms/browsers, but the focus of that need isn't upon increasing reach or audience in most cases. Instead it's a question of availability and productivity for the end users. Similarly, with most web applications, it's safe to say that some conditions (such as the specification of minimal browser versions or the requirement of "plug-ins" like Silverlight) are not only acceptable but go hand-in-hand with meeting primary goals and considerations (instead of coming at the expense of those goals and considerations).

Why This Latest Little Tussle Mattered
Yet in the case of site or app development (as I've outlined above), we'd still be talking about web development being done by web developers—because everything would be client-server oriented and rendered in a browser. From there, the similarities quickly fade, though. And problems creep in when application developers fear that they may lose their productivity tools, features, and capabilities to something that just doesn't meet their needs in the same way (HTML 5, CSS3, and jQuery). The same can be said when application developers try to argue that HTML 5 just isn't rich enough to handle "true" web development—because site developers are currently building REAL web solutions and sites with HTML 5 today.

Consequently, until our industry at large can learn to more readily distinguish and elucidate the differences between application web development and web site development, I think we're doomed to endure two painful consequences.

First, we're doomed to more flare-ups like the one we just saw, as this whole HTML 5 vs. Silverlight scuffle perfectly reinforces the fact that there are two primary types of web development out there today (along with variations or "blends" of these two techniques in various shades and colors).

Second, and much more important, I think we're also doomed to not being able to communicate our specific development needs for tooling, platforms, and patterns as readily as we should be able to vendors and industry "shapers" like Adobe, Apple, Google, Microsoft, the W3C, and so on. Meaning that if we're going to erroneously fight about which single tool or technology is best for both kinds of development, then we risk sending very mixed messages to the very companies and powerhouses that build the browsers and tooling that we all need to stay gainfully, and professionally, employed and viable.

To that end, I think it's important to point out that not only do I think that the world is big enough for both technologies, but I actually think that there's a need for both HTML 5 and Silverlight. And, happily, it looks like Microsoft is going to be heavily investing in both of them. So, hopefully, we can all get back on track and do a better job of communicating just what it is we need from Microsoft, instead of trying to convince them (or ourselves) that a hammer is better than a saw, or vice versa.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.