This is a real gem of an article that outlines a core comparison between HTML5 and SL5.
The goal of this paper is to present an objective comparison between Silverlight 5 and HTML 5 (with: JavaScript / ECMAScript 5 + CSS3 + any required additional frameworks and APIs). We will only focus on some features: covering these technologies entirely would require a whole book. The main idea is to provide a guide to help you choose a technology as part of a planned project.
The good news is the SL remains a great choice.
And, here are the 7 parts I think LOB developers should read:
1. HTML 5 has no support for User Controls: HTML 5 does not offer any integrated solution for creating controls except basic copy/pasting of code. This is a big minus for business projects looking at industrializing their developments. We are far from the plethora of controls that can be simply referenced in Silverlight.
2. HTML 5 has no support for Databinding: In the land of HTML 5 there is nothing. This implies that HTML 5 is heading more towards the production of consumer websites where Silverlight 5 aims at business line type of applications. To do databinding in HTML 5, we will necessarily go through Javascript code to manually assign values to controls and subscribe to events to retrieve the changed data. Some libraries exist (for example, you can use jQuery or Knockout) but nothing as effective (in terms of implementation and performance) as Silverlight.
3. HTML 5 has weak Threading Support: HTML5 has the concept of Web Workers, threads that are independent from the main thread (the one that displays and manipulates the DOM). For Silverlight, communication with other threads is done by calling methods and passing parameters (in fact, nothing special). Silverlight outperforms Web Workers on potential and tools but also in terms of control over the threads. The addition of future technologies such as Async Framework will add even more power to Silverlight.
4. HTML 5 has weak Web Service support: Regarding web services, Silverlight with Visual Studio allows us to make a simple [Add Reference]. It generates the local proxy to call a web service (WCF for example) using the HttpWebRequest. In Javascript, it is less easy because the tools are not (yet) available but it is still possible for example to use the AJAX framework. Otherwise you will have to write your own queries and handle the protocol. We must therefore recognize that Web Services/WCF & Silverlight offers a much easier implementation.
5. HTML 5 has weak Device Access support: Silverlight 5 provides access to the datastream from the camera or microphone. It can also send a print job controlling the drawing of each printed page. HTML 5 on the subject is currently a bit light in terms of access to the camera or microphone.On the topic of devices access, Silverlight 5 wins by a large margin (for now).
6. HTML 5’s Standard is Unfinished: One should not be lulled by the myth of absolute portability of HTML 5. For now, the standard is evolving and will not be completed until 2014 at best. During this time and certainly for a long time afterwards, the browsers will be trying to support the standard. Thus, it will force us to write more code than necessary sometimes for specific versions (besides there is a JavaScript library that facilitates this work modernizr).
7. HTML 5 protects IP, but not as well: A final important aspect lies in the protection of intellectual property. There are obfuscators for both technologies (for example this one for Javascript) but we can see that as a result of compilation, Silverlight (IL) is more difficult to reverse engineer. In addition the XAML is not directly exposed: it is easier to get the HTML (directly sent to the browser).
Read the whole article for yourself, here.
If I could throw in my 2 cents, I would add that we should all remember that HTML5 is really version1, while SL is version 5 and completely managed by Microsoft. As scary as that may sound, the reality is – infighting between browser manufacturers (which is inevitable) remains moot with SL. The power of data binding alone makes XAML-based applications a slam dunk for data-driven line-of-business apps.
Someday HTML 5 may be a better choice, but that’s someday and it may never come. Today, SL reigns. However, if you really are building line-of-business applications, consider WPF. If SL dwarfs HTML5, then WPF dwarfs SL – and they are both Managed Code and XAML-based. WPF has more controls, richer binding options, animation options, trigger options, and so much more. Take a look.
Note: Please read that I said line-of-business applications! General and public web sites are not the same story. Their needs for managing data, eventing and threading are far less. For those sites, do not ignore the reality of HTML 5. It is (and will grow more) powerful and is very likely your absolute better choice.