HTML 5 or Silverlight?

| Posted by Daniel Jebaraj Follow 0 Followers on Aug 08, 2011. Estimated reading time: 10 minutes |


In a rare moment of frustration, Albert Einstein said that perfection of means and confusion of goals seemed to characterize the age. One might think these were the words of a software developer, not a physicist.

As development platforms continue to evolve and improve, the forest is sometimes lost in the trees. Such confusion can be seen in the ongoing debate regarding Microsoft Silverlight and HTML5.

Some think that Microsoft is going to abandon Silverlight as momentum for HTML5 continues to grow. This does not appear to be true. While Microsoft has shifted its strategy for Silverlight, no longer touting it as the vehicle for delivering a cross-platform runtime, it continues to push it as the development platform for Windows Phone as well as for some media and line-of-business applications. Silverlight is not going away. In fact, Silverlight 5 in its final form will be available this year, and the tooling support for which Microsoft is legendary will back it up.

While HTML5 is a draft standard, its ultimate role as the dominant cross-platform solution is a fait accompli. Even Microsoft acknowledges this, calling HTML “the only true cross-platform solution for everything.”

Basically, Silverlight and HTML5 both have their place and purpose, as a close look at the similarities and differences of the two tools will reveal.

Similarities on the Surface

At first glance, HTML5 and Silverlight are similar in a number of ways. The similarities are tied to ease of deployment, the richness of the user interface, and the interaction model.

One of the concerns with the desktop, especially for Windows developers working within the Windows environment, is deployment. This is an issue for those working in mid-sized to large companies. The deployment footprint for desktop applications is quite troubling for them because they have to ensure that a certain version of the runtime is available, and they have to get updates to every machine. Therefore, deployment has been a pain point for richer desktop applications.

In some cases, the business reasons for sticking to desktop applications will continue: better performance and better use of native hardware—simply getting things done in an easier, more seamless manner. Plus greater programmer knowledge exists for development scenarios on the desktop platform. These reasons can override the need for easy deployment.

For customers to whom deployment is a central priority, pure Web solutions may be preferable, although not all customers will be happy with the richness delivered vis-à-vis what is available in the desktop application. Such concerns must be balanced as alternative solutions are explored.

In general, both Adobe Air and Silverlight are good solutions. Within the Microsoft stack, Silverlight is a very good solution, because even though there is a runtime, it is structured for seamless deployment and it is easy to get users updated. Essentially, Microsoft takes care of the updating experience. You don’t have to worry about getting the application down to end-user machines.

HTML5 provides a similar deployment scenario; however, it has hidden traps because it relies on a browser. The team using an HTML5 solution has to be reasonably sure that their customers will have access to the latest browsers and will install them. In addition, HTML5 has broad support: IE9, Chrome, and Firefox support it; IE10 will work better with it. All mobile clients will support it in the future, even if they do not now.

In short, while a small deployment difference exists between Silverlight and HTML5, the deployment model is basically seamless in both.

In terms of richness of user interface (UI), Silverlight has some advantages. To get a rich UI done quickly, Silverlight is probably a better solution. Nonetheless, HTML5 is catching up to Silverlight in this regard. Soon it will have much more prepackaged content available to facilitate the building of rich UI environments.

The two tools are also comparable in terms of their interaction models. Neither demands that one wait for a page refresh, and working with either is similar to the way one works with a desktop application.

On Closer Examination

The strong functional similarities between HTML5 and Silverlight tend to dissolve on closer examination. First, Silverlight is more suited for intranet applications that have relative control over the deployment environment than for true Web-based deployment.

If you look a little deeper at the deployment scenario in Silverlight, it is still not a true end-user solution. So if the developer’s purpose is to have application users download Silverlight and run it on their machines, then the developer needs to have a good picture of the customer. Is the customer going to have a system that can run Silverlight? Is it something that will be allowed?

For example, if a user goes to, it’s probably not a good experience to be prompted to download the Silverlight client. For Web site use, the more seamless the experience, the better.

However, in cases of an intranet solution—where developers have more control over the machines and know that they are Windows machines—they may not have quite the degree of control needed for a desktop application, but they know that those machines are capable of running Silverlight. That provides the developer with a great deal of flexibility.

Now he or she can choose to go with Silverlight; when compared to HTML5, it is definitely a more productive development experience.

Microsoft has excellent tools that make it easy to build and deploy applications with Silverlight. HTML5 requires a bit more work while Silverlight is more structured—the tools are in a class of their own. If you are confident that your deployment environment is relatively familiar to you, perhaps a close band of customers to whom you can say, “these are the minimum requirements,” then Silverlight is more suitable. This is further supported by the quality of Silverlight tools, which empower the developer to build Silverlight applications in a quick, drag-and-drop manner. Silverlight also makes UI development, and most other development, highly productive by using the built-in control abstraction model and native controls that Microsoft has provided.

HTML5 on the other hand requires support from your current web-application tool. If you are developing in ASP.NET, that would be Visual Studio .NET, which doesn't provide any tooling support for HTML5, as is probably the case with many development platforms currently.

Lingua Franca or Straining to Understand?

Programming language is another consideration. C# (Silverlight) is easier to work with and debug than JavaScript (HTML5). It goes back to the tooling and the nature of the language. JavaScript is a different beast to work with; even experienced JavaScript programmers know that it is a bit harder to understand because it is a procedural, type-unsafe language by nature, whereas C# is an object-oriented, type-safe language. This basically means that large sets of code are better written and maintained in C# than in JavaScript.

Silverlight Limitations and Other Considerations

Silverlight is limited if mobile deployment is required. Currently, Silverlight is only supported on Windows Phone. It may be supported on other platforms in the future, but this is not certain. It’s not something that is likely to happen in the short term. Currently, to develop a Silverlight application that mobile clients can use, the Windows Phone device must be mandated.

If developers don’t have control over their mobile clients, yet they want to support them, HTML5 is a viable option. Already supported by iOS, Android 3, and with Windows committing to support it in IE10, HTML5 is the clear choice right now.

However, Silverlight may offer better performance than HTML5. Over the last few months, Microsoft implemented a hardware solution for Silverlight 5, so it may offer a slight performance advantage over HTML5 on newer machines. But there is no reason that HTML5 won’t catch up. IE9, for example, does a lot with HTML5, so this performance difference is more transitory than decisive. It isn’t much of a difference.

Notably, HTML5 is a standards-based environment, something of great concern to some developers but of little concern to others. If a developer is working on the Microsoft stack, he or she will be aware of and have an appreciation for standards; however, this is mitigated by the understanding that Microsoft is going to be around for a while, so there isn’t a reluctance to adopt proprietary technologies from Microsoft.

In many cases there is a push to adhere to standards, so that if things change, the migration path is easier. HTML5 is standards-based and about as global as it gets. The path forward is very clear with HTML5—with Silverlight, less so.

Silverlight has a considerable advantage over HTML5 in that 90 to 95 percent of code can be shared with desktop applications. If you have a full-fledged desktop application and a solution to get on the Web, it’s easier with the Silverlight model.

In HTML5, developers can keep the UI separate and have a business layer; however, a great deal of UI code has to be written on the two platforms, which takes more effort and allows almost no code sharing.

Means to an Informed End

In the end, the tools must be selected with a clear goal in mind to avoid the confusion Einstein identified. Choosing the right path based on one’s needs will minimize the likelihood of expensive mistakes. For example, developers may be comfortable with WPF and Silverlight and so choose that path, but after exploring what they want to do with the application, they may hope to launch a mobile client within six months to a year. What’s more, they want people with multiple devices to have access.

At that point, it’s okay if they go with the Silverlight solution up front, as long as they are prepared to eventually go to HTML5 or write native applications for each mobile platform. If not, this will be a very expensive choice.

The flip side holds as well: there may be a push to go with HTML5 because everyone is saying, “this is the future.” So a decision is made to go in that direction, even though the customer has Visual Studio for all its developers and is licensed to use the latest and greatest Microsoft tools.

If they have good control over the deployment environment, and if they’re not going to put in Linux or Mac devices in the next six months, then they’re probably making an expensive mistake. They could have gone with Silverlight, which would have allowed them to get to market faster, as well as use their current skill set and toolset more effectively.

The bottom line: as long as developers make an informed choice, either Silverlight or HTML5 is fine.

Applying the Best

Microsoft has no control over the mobile market right now since they have to support HTML5 strongly. They’re not dictating terms, and it’s questionable whether they would if they could. Microsoft’s strategy is to apply the best tools and platform possible, regardless of whether it is proprietary.

According to Microsoft, “On the web, the purpose of Silverlight has never been to replace HTML; it's to do the things that HTML (and other technologies) couldn't in a way that was easy for developers to tap into. Microsoft remains committed to using Silverlight to extend the Web by enabling scenarios that HTML doesn't cover. From simple islands of richness in HTML pages to full desktop-like applications in the browser and beyond, Silverlight enables applications that deliver the kinds of rich experiences users want.”

These words underscore what is apparent to us: Silverlight and HTML5 will both thrive in the foreseeable future.

About the Author

Daniel Jebaraj leads Product Development at Syncfusion, an enterprise technology partner for developers on every Microsoft platform, delivering the broadest range of .NET components and controls coupled with a service-oriented approach throughout the entire application lifecycle. 

He oversees overall product development and plans for specific releases. By actively engaging with customers, Daniel ensures that each new product improves based on customer feedback. Previously, as Vice President of Development, Daniel focused on driving product development at Syncfusion.
Before joining Syncfusion in 2001, Daniel managed development teams at Rogue Wave Software.

Daniel holds a Master's degree in Industrial Engineering from Clemson University.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Large apps in JavaScript by Alexey Lapusta

JavaScript is a different beast to work with; even experienced JavaScript programmers know that it is a bit harder to understand because it is a procedural, type-unsafe language by nature, whereas C# is an object-oriented, type-safe language. This basically means that large sets of code are better written and maintained in C# than in JavaScript.

That's simply not true. JavaScript is an object-oriented language. It's just using prototype-based inheritance instead of class-based one. And with right patterns applied it doesn't stop you to develop testable and maintainable large scale apps like Google Docs/Mail or Microsoft Office 365.

Re: Large apps in JavaScript by Russell Leggett

Yeah, when somebody calls JavaScript procedural, its hard for me to take the rest of what they say seriously. It has no classes, we get it!

Subjective by Clint Hill

C# (Silverlight) is easier to work with and debug than JavaScript (HTML5)

Completely subjective.

I love when these statements are added to imply some form of justification.

Re: Large apps in JavaScript by Faisal Waris

Javascript was never designed for large apps. It was meant for simple scripting on a web page.

Javascript is 'powerful' but it gives you enough rope to hang yourself and then some.

Today it is being used for large apps but only by necessity. There is no other language widely supported to run inside the browser so we are stuck.

Had the world known about web 2.0 earlier, it would have designed an appropriate language for the task.

Java was designed was to be a 'web' language with its sandbox security but that never panned out.

Re: Large apps in JavaScript by Alexey Lapusta

Javascript was never designed for large apps. It was meant for simple scripting on a web page.

Javascript is 'powerful' but it gives you enough rope to hang yourself and then some.

Today it is being used for large apps but only by necessity. There is no other language widely supported to run inside the browser so we are stuck.

Had the world known about web 2.0 earlier, it would have designed an appropriate language for the task.

Java was designed was to be a 'web' language with its sandbox security but that never panned out.

You can do Java in browser via GWT, Objective-J allows you to develop apps using Cocoa API, Yahoo YUI & Google Closure provide solid base for writing complex apps via plain JavaScript. You can write tests, use JSLint for static analysis, ES5 brings you more new functionality, like strict mode.

I also agree, that with basic knowledge of JavaScript and jQuery it's very easy to screw the development of complex app, and that Flex & Silverlight are more suited to build complex apps, because they were designed for it, have less flaws and limitations.

Business Applications by Jordan Pollard

I develop with both Silverlight and HTML5. Silverlight has some massive advantages over HTML5 especially as we start to look towards Silverlight 5 and the graphics capabilities, but not all of these capabilities are available unless you are using Out-Of-Browser mode. In the browser, they start to have comparable capabilities, but I want to make sure it's clear that javascript is 3x slower than C++ and that can make a huge difference when you're looking for a responsive client. When it comes down to it, you can develop your services to be fairly cross compatible so it's about the UI. We do indeed have clients who want to access our product on Android tablets and iPads - we are considering HTML5 as a temporary solution, but we don't see it as being more than a temporary solution because Apple and Google are never going to support HTML5 as much as they support their native languages. No matter how much they pretend they are all about open source, in the end they are all about keeping tight control over their product so it cannot be hijacked. IMHO, native apps are the way to go especially for apps like ours where we are working with graphics intensive processes and real time upates (in our case this is for tracking helicopters, ambulances, etc...)

The title is hilarious by Jochen Szostek

Comparing HTML5 to Silverlight is like,
comparing science to religion.

Re: Business Applications by cisco kidicantec

Hi Jordan - Just in case you have not seen this post about the new Web Sockets.

Its interesting to think that C++ is a real time language, when you have little control over the exact machine code generated and the libraries used.

In fact you really need machine code/assembler to generate proper real time hardware tracking. If you re-compile c++ code on a different computer architecture then the results change.

So high level languages are really best at simply disseminating the information from the instrumentation.

Drank the KoolAid - Feeling a Little Queasy by Don Rule

I have the first version of my app running on Silverlight including using the RIA domain model.

The app looks great but I quickly learned that virtually no application is relevant today without a robust mobility story.

I assumed that porting to Windows Phone would be just some UI reformatting but you have to implement some basic things - like caching authentication credentials. What is more the RIA infrastructure was not available for the phone yet. So there was some application tweaking as well as ui reformatting.

But even once you have the phone version it is pretty rare that you can convince someone to buy a Windows phone just to get your app. And the tablet story compounds the issue.

So at the moment my strategy is to develop an HTML5 app and see what the performance is like. I can port it it via PhoneGap to semi-native and then do full-on native iOS or Android if it becomes necessary.

I like Silverlight but I think that it will be extremely rare that you can develop a viable app without an HTML5 client. If you can afford to develop multiple clients then Silverlight is a great solution but other than that I think that it is a dead-end unless Microsoft makes it available on platforms that really matter.

Don Rule

Re: Large apps in JavaScript by Daniel Jebaraj

Sorry, I should have been clearer. What I meant to say is that most Javascript code in the real world tends to be procedural though this has started changing in recent times. The object-oriented features of Javascript are often overlooked and are quite frankly not very intuitive to someone from a C++/Java background.

It is absolutely true that it is possible to write applications such as Google Docs with Javascript. In my opinion (and strictly my opinion) it is easier to write similar applications using C# and the .NET runtime.


Can you post some quick analysis by shashi kanth

can you collect some analysis of HTML 5 Vs Silverlight supported machines, if you do this you will definitely delete this post.

I am big fan of microsoft products but time is changing my view.

I think its the HTML5 era tomorrow and microsoft is just loosing its way to stand strong.

please watch some of the experiments done by Microsoft, Apple and Chrome. I am able to experience HTML5 without download any plugin and I am seeing experience in all media options at my end.

Re: The title is hilarious by Andrea Del Bene

LOL :D!!!

Re: Drank the KoolAid - Feeling a Little Queasy by Faisal Waris

Mobile has thrown a wrench in the web works.

Google, Apple and Microsoft all make money from native apps. Don't know if they are willing to support HTML5 to actually enable cross-platform mobile apps.

Re: The title is hilarious by Chu Jack

wow, good analogy

Better comments, not so great article by Srikanth Shreenivas

Comments in this article are more interesting than the article itself.

Re: Large apps in JavaScript by Dan K

Actually, it is my understanding that Office 365 is written using Script# (developed by god Nikhil Kothari). Script# is a C# compiler that compiles to Javascript rather than IL.

So all of the code management, in this case at least, is outside of the javascript itself.

HTML5/JS is the runtime - Silverlight will be the development environment.. by Douglas Stein

One obvious solution to the confusion is if Microsoft simply makes it possible to target multiple runtimes (HTML5/JS vs. Silverlight) from .NET languages. Wouldn't it be cool for a C# or VB.NET (or even F#) developer to be able to use a robust development and debugging environment such as Visual Studio and/or Expression and still run on any HTML5 browser.

I suspect Microsoft has kept things quiet before Build because they're goung to do a Big Reveal (TM). They might also try to get some partners to launch such web apps on iOS just to show that you can create fluid web apps without kowtowing to the control freaks running the Apple store.

By targeting HTML5/JS as a portable runtime, Microsoft wouldn't be held up waiting for Apple to bless a Silverlight runtime for iOS (like that would ever happen). They get ubiquity without chasing their tails constantly porting versions of the classic Silverlight runtime over and over as the number of phone/tablet/TV/etc. platforms proliferate.

Re: Large apps in JavaScript by Albert Arul Prakash Rajendran

I was a silverlight/.net/classic ASp/Javascript devleoper a year ago now in product management team. So I believe i am capable to join technology discussions.

Yes you can create similar application with ease, but .Net lacks a lot of things by itself which was enjoyed by C++ developers. Silverlight Lacks a huge load of items. Lot of things that were available in legacy language (aka classic asp, native DOM based XML) are not available in .net languages.

The capability of customization without recompiling is absolutely not available in .net (for web) this poses a huge risk for lot of web based products to provide source code along with the binaries to customer.

Recent times there is Prism/CAB (winforms) that supports components and movable parts model. But it is still not available much for web. With HTML/JS we do have some frameworks that supports this.

if written properly you can develop any application in any language with ease.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss