This article compares Silverlight and KnockoutJS (http://knockoutjs.com/) by looking at the implementation of the same application with both frameworks. During this comparison we’ll see that there are a great many similarities between the two frameworks, with the same concepts appearing in each. However, the execution / realisation of these concepts is quite different. Finally, we’ll look at the all-important question: "Which is better, Silverlight or Knockout?"

There is no denying that the popularity of HTML5 and JavaScript is on the rise. Complex web applications which were previously the domain of plugin technologies (Silverlight, Flex, Flash, Java Applets) are now increasingly being written using JavaScript. Which technology to choose for a particular web development is the subject of another article altogether (Flex, Silverlight or HTML5 Time to Decide …), this article instead focuses on Silverlight developers and how they can make the most of their existing skills by using the KnockoutJS framework.

So why KnockoutJS? Good question! To help answer this, we’ll take a brief look at the differences between Silverlight and HTML5 / JavaScript development.

Silverlight has three main components, the first is the language itself (C# or VB.NET), the second is the core libraries that are common to all .NET languages, and the third is the Silverlight framework itself, which includes concepts of controls, animations and XAML. With JavaScript development things are very different, the language itself fulfils the same role as C#, however there are no standard libraries that perform the same functions as the core .NET and Silverlight APIs. Instead, there are numerous frameworks that fill the gaps and a typical JavaScript application will make use of a range of these.

There are a number of JavaScript frameworks that support pattern-based UI design (MVP, MVC). You can see a practical demonstration of 16 (yes 16!) different UI frameworks in the ToDoMVC project, which re-implements the same simple application with each framework. For the Silverlight developer wishing to learn JavaScript application development Knockout is an obvious choice because it supports the Model-View-ViewModel (MVVM) pattern, which is the UI pattern ‘baked in’ to the Silverlight framework. Knockout is relatively new, first being released in 2010. It has also attracted the attention of Microsoft, who recently hired Steve Sanderson, the creator of this framework. However, Microsoft did not acquire Knockout, which remains an open source project.

NOTE: Throughout this article I will refer to CSS, HTML, JavaScript and Knockout collectively as just ‘Knockout’. All four are quite distinct technologies in their own right, but for brevity, we will consider them all to be components of our Knockout solution.

In order to introduce Silverlight developers to JavaScript and Knockout development, this article will describe the development of a simple application using both technologies. The application is a Quiz, with screenshots of the Silverlight and Knockout versions shown below:

Silverlight Version

Knockout Version

As can be seen from the screenshots above, the two versions of the application look virtually identical.

Both applications have exactly the same view-model structure, shown below as a simple model:

A brief description of the view models and their responsibilities is given below:

QuestionViewModel – this details a single question, which includes the question text itself, together with the possible answers. This view model also stores the answer which the user selected.

AnswerViewModel – this details a single potential answer to a question. This view model does not contain any dynamic state.

ResultsViewModel – this details how many questions the user got right. An instance of this view model is generated dynamically when they complete the quiz.

QuizWizardViewModel – this view model manages the overall application flow, navigating from one question to the next as indicated by the CurrentQuestion property. When the user has answered all of the questions correctly, this view model generates a ResultsViewModel instance.

The above view model is pretty standard in that it contains a number of properties which will be bound to the UI. These properties fall into two classes, the first which we consider to be immutable (i.e. their value does not change) which are just regular properties; and the second, which change as a result of UI interactions or application logic, these are implemented to raise change notifications via INotifyPropertyChanged.

Because of the boiler-plate code involved with INotifyPropertyChanged, the view-model extends a common base class:

One of the first differences here is that the view-model itself is a function rather than a class. This is because JavaScript is not a strongly-typed language, i.e. you do not define your own types (classes) then construct instances of them. Instead, objects can be built dynamically by adding properties and functions to them. The above code defines the view-model using a Constructor Function, in other words QuestionViewModel is a function which constructs an object, dynamically adding properties to the object and setting their values. For further details I would recommend reading the article "Object Oriented Programming in JavaScript" by Mike Koss.

In common with the Silverlight view-model there are properties which we do not expect to change, such as text and index, and those which do change, e.g. selectedAnswer. In the above view-model selectedAnswer is constructed via a call to ko.observable(). This function creates an observable property, which has a built in mechanism for notifying subscribers of value changes. This is the Knockout equivalent to INotifyPropertyChanged.

It is worth noting that in Silverlight properties and property accessors are a first-class feature of the language, where an auto property with a private setter provides a convenient shorthand for creating immutable properties. JavaScript on the other hand does not widely support the concept of getters and setters (this is a recent language feature that some browser do support), but in order to maximize ‘reach’ Knockout does not use it). As a result of this, JavaScript does not support immutable properties. Furthermore, the lack of getters and setters means that the use of ko.observable means that the selectedAnswer property cannot be set like a regular property, instead it must be invoked.

Before launching into a complete view, we’ll take a look at the binding syntax of each framework. Both share the concept of a data-context, where the regions of the application UI are ‘backed’ by a view model, such that it is the source for any binding defined within that region. With Silverlight you simply set the DataContext of the view to the view model:

this.DataContext = new QuestionViewModel(...);

Whereas in Knockout you invoke the applyBindings function:

ko.applyBindings(new QuestionViewModel(...));

Not much difference there!

Note that Knockout has the concept of a data-context, which is called the binding context within the documentation. However, unlike Silverlight it is not a property that you can set or inspect directly.

With Silverlight you can bind to any dependency property of an element within the visual tree. Bindings are typically defined using the {Binding} markup extension:

The above text binding will render the value of the index property within the body of the span element. Knockout has a small handful of built-in bindings for text, css and visibility, together with a generic attr binding that can be used to bind and attribute of the element to a view-model property.

While Silverlight and Knockout bindings look similar on the surface, there is one quite significant difference. Both frameworks expect you to bind a property value that is compatible with the binding target. With Silverlight, this means you often find yourself requiring type converters for properties such as visibility. Whereas, with Knockout, JavaScript type coercion and the fact that most DOM properties can be set as strings, means that type conversion is rarely needed.

With Silverlight you can bind properties to the UI that do not raise PropertyChanged events, this results in a one-time binding, i.e. the initial property value is set on the UI element, but any subsequent updates are ignored. Likewise, with Knockout you can bind properties that are not observables and achieve the same effect.

Now that we have a basic understanding of view models and bindings, we’ll look at how these are put together into a view. With Silverlight, the UI is composed of user controls (or custom controls), which are defined using XAML. A common approach with the MVVM pattern is to define a separate view for each view model.

The MainPage.xaml which is the starting point for our application contains a single instance of QuizWizardView:

The visual tree DataContext inheritance will ensure that the DataContext of our QuizWizardView is the QuizWizardViewModel instance created above. Running the application with the code so far, we see a beautifully shaded square with round borders, plus our quiz title:

With Knockout, the approach is quite similar. Our application runs within the context of a HTML page, which includes the various scripts. The views are defined as jQuery templates, which allow re-use of the same UI markup:

Whilst the way in which the UI is constructed is very similar between Silverlight and Knockout, both of which have a mechanism for creating views via user controls and templates respectively, the markup for the UI itself is quite different. Anyone who has created UIs from XAML and HTML will understand that the two are quite different. XAML is geared towards creating applications, whereas HTML is geared towards presenting content. For this reason, something which is quite trivial in Silverlight, such as vertically centring content is actually pretty tricky in HTML, and conversely, creating a graceful flowing responsive magazine-style layout is almost impossible in Silverlight.

Another significant difference between Silverlight and Knockout applications is styling. In brief, Silverlight styles are simply collections of property values that are applied to elements via explicit references to the style. HTML is styled via CSS, which provides a complete separation between markup and style, where elements are matched using CSS selectors. The CSS for the quiz application is given below:

Now that we’ve seen how the view is defined in both Silverlight and Knockout, and looked at the basic binding syntax for each, we’ll look into a more complex problem. Each question has a category, which is used to pick an image to accompany it.

The Silverlight QuestionViewModel has a string property, Category. In order to render this within the view, it is bound to the Source property of an Image element:

This sort of thing is much easier with Knockout. Firstly, the src property of an image element can simply be set to a string value, so we are able to bind to it directly. Secondly, Knockout permits you to use expressions directly within the bindings themselves, removing the need for value converters:

Note that Knockout doesn’t have a specific binding for the src property, so we use the generic attr binding.

With a simple bit of styling, both versions of the quiz application now render an image for each question:

The Silverlight quiz application has no less than five value converters. In each case the Knockout implementation is much simpler due to the lack of strong typing, or simply due to the HTML elements accepting string values. Knockout also has a visibility binding, which provides a convenient way of showing / hiding an element based on a boolean view model property.

Again, a value converter is being used, this time to convert the index of each answer to a letter.

Knockout supports collection binding via a template with a foreach property. The markup below iterates over each of the items within the answers array, rendering an instance of the answerView template for each of the items. Any databindings within the answerView template have the answer instance as their datacontext:

Resulting in a UI which looks exactly the same as the Silverlight one:

Again, the Knockout collection binding is very similar to Silverlight, you can bind to collections that do not raise change notifications, for example in Silverlight you can use an ItemsControl to render a regular List, while in Knockout a foreach binding can render a regular JavaScript array. For change notification Silverlight uses the INotifyCollectionChanged interface (most typically via ObservableCollection), whereas Knockout uses observable arrays. An observable array is defined in exactly the same way as a regular (single-valued) observable property:

this.answers = ko.observableArray();

Both frameworks take care of handling when items are added and removed from collections in order to keep the view synchronised.

In the previous section it was shown how both Silverlight and Knockout collection binding can be used to render the potential answers to each question. But what happens when the user clicks on the answer that they think is correct?

Within the Silverlight version of the quiz application we can bind the SelectedItem property of the ListBox to a property of our view-model. When the quiz is complete we can simply total the number of questions where question.SelectedAnswer.IsCorrect is true.

The Knockout UI is HTML, which does not really support the concept of controls and as a result the ul / li elements used to render the answers for a question do not support the concept of selection. With the Knockout implementation we have to add a click event binding which invoked a method on one of our view models:

Knockout does have a selectedOptions binding which is almost what we are after here. As a general observation, Silverlight has a much stronger concept of UI controls, which can expose control-specific properties that can be bound to. This allows for complex UIs to be built quite rapidly from a suite of common controls, of which Silverlight has around 30 as part of the SDK and many more via third party suppliers.

The current quiz application is a little plain, we’ll try to make it more interesting (at least within the confines of my artistic ability!) by adding a subtle highlight effect when the user hovers over each answer.

With Silverlight, transitions can be specified using the visual state manager. Controls are able to define visual states, such as checked, focussed and mouseover, you can then use the visual state manager to define the UI for each state and how to transitions between states. For our quiz application we’ll create a subtle highlight effect on mouse over:

The style above defines the template and visual state transitions for the ListBoxItem, which is generated by the ListBox as a container for each item within the list. In order to use the above style, we set the ItemContainerStyle:

This gives a subtle mouse over effect for each answer, which acts as a handy visual cue that these items are clickable:

Visual states are another facet of the Silverlight concept of ‘controls’ and as a result, Knockout does not share this same feature. However, because the Knockout UI is defined as HTML, we can use CSS to achieve the same effect.

We can use the hover pseudo-selector to specify the mouse-over colour of each answer. But how do we create the subtle fade in / out effect? With CSS3 this is very simple. We can simply specify a transition for the background-color property:

The transition indicates that any change in the background colour property should transition from the previous colour to the new over a period of 400 milliseconds.

The implementation of this same effect is very different between Silverlight and Knockout, with the Silverlight version being quite a lot more verbose. So why is this? There are a number of reasons; in order to define a visual state transition, you must re-template a control, replicating its existing template. Silverlight animations are strongly typed, therefore we have to choose the correct animation type for each property. Finally, Silverlight uses XAML to define the templates and storyboards which is always going to be a more verbose than alternatives.

I know which approach I prefer! The simplicity of the CSS3 approach, where the type of the property being transitioned does not change the syntax, is so much easier to implement. The lack of type-concerns is a common theme with Knockout development. Furthermore, a CSS3 transition will ensure that a property value transitions regardless of the mechanism used to set its value. Finally, the separation between style and markup that HTML and CSS provide is much superior to the separation that can be achieved in Silverlight.

Although, in Silverlight’s defence, the concept of visual states is entirely extensible, you can define whatever visual states make sense for your control and provide transitions between them.

The QuizWizardViewModel exposes the current question view model via its CurrentQuestion property. With both the Silverlight and Knockout quiz application the user clicks on a ‘next’ link which advances the quiz to the next question.

The QuizWizardViewModel within the Silverlight application exposes a NextQuestion command:

In a more complex application this would be a good candidate for using a generic ‘delegate command’, but as this application only has a single command, we’ll follow the YAGNI principle and use the above implementation.

Within the view we include a button that binds to this command so that when it is clicked, the above code is invoked:

The Knockout implementation of this functionality is again much simpler than the Silverlight version. The Silverlight concept of commands is more powerful than simple event-to-function wire-up, with features such as command-properties and the ICommand.CanExecute property which can be used to automatically disable a button (or other UI control) when a command cannot be executed. Although, in practice, these extra features are often not required, furthermore, command binding can be a little patchy within the Silverlight APIs, some controls which really should support commands do not, leading people to use solutions such as MVVM Light’s EventToCommand behaviour. In order to avoid the whole command complexity, the Blend Interactivity SDK includes event triggers and a CallMethodAction that allows you to wire an event directly to a method invocation, just like Knockout.

So far our comparison has focussed on features that are present in some shape or form in both the Silverlight framework and Knockout. In this section we’ll take a brief digression to look at a few rather neat features that Knockout has that lack a Silverlight equivalent.

In the previous section which looked at command binding we saw how the QuizWizardViewModel is responsible for navigating from one question to the next. Within both the Silverlight and Knockout applications the ‘next’ button lives within the template for the QuestionViewModel, so how do we wire up this button to invoke a command on the QuizWizardViewModel when the data-context of our UI is a QuestionViewModel instance?

Within Silverlight there is no direct support for this scenario. However, the solution to this problem is relatively simple, we add a relationship from the QuestionViewModel back to the QuizWizardViewModel as follows:

You can also solve this issue via some sort of fancy relative-source bindings.

Even though the solution is relatively simple, I would rather not have to maintain bi-directional relationships within my code if I can help it. They provide the opportunity for all kinds of interesting errors if you need to move child elements from one parent to another.

The Knockout solution to this problem couldn’t be simpler. Whenever the binding context changes through a template binding (or with binding), the parent view model is accessible via the $parent pseudo variable. You can even locate the n’th parent via the $parents array, or locate the top-most view model via $root. As a result, the Knockout binding for the ‘next’ button click does not require any changes to our view-models:

Another very useful feature of Knockout is computed observables (previous called dependant observables). The QuizWizardViewModel for both the Silverlight and Knockout implementations stores the current question as an index into the array of questions. The Silverlight QuizWizardViewModel exposes the current question as follows:

This is pretty straightforward stuff, however, when creating properties that are derived from other properties of your view-model you must be careful to raise property change correctly. In the example above, whenever _questionIndex changes, we need to raise a property changed event for the CurrentQuestion property. This is pretty trivial in the above example, however with view-models that have properties that are derived from a number of other properties, this can become something of a maintenance nightmare.

Knockout has a very elegant solution to this problem, you simply create a computed observable, defining a function which is used to determine its value:

The framework ensures that whenever an observable property changes that impacts the value of a computed observable, any subscribers to the computed observable are notified of a change, resulting in bindings being updated.

So how does Knockout perform this magic? It’s actually quite simple really. When a computed observable is first created, Knockout invokes the evaluator function (i.e. the function you supply to Knockout which defines the property). Whilst this invocation is running, Knockout keeps a log of any observable property getters that are invoked and as a result it can determine the dependencies of the computed observable. Neat.

When the user has answered all of the questions, the number of correct answers are totalled and the results displayed. In order to achieve this the QuizWizardViewModel constructs and exposes a ResultsViewModel instance which causes the view to render the results template using techniques we have seen earlier in the article. However, the way in which the number of correct answers is totalled highlights another interesting difference between Silverlight and Knockout.

The Silverlight implementation uses a Linq Count query to count the number of correct answers:

However the way in which the number of correct answers is totalled highlights an interesting difference between the frameworks. Silverlight applications have access to a huge range of utility classes, APIs and tools which are all part of the .NET Base Class Library (BCL). The Linq Count query used in the code above is part of this standard library and can be employed within a WPF, ASP.NET, WP7 or any other .NET application.

In contrast, the JavaScript language lacks an equivalent to the BCL, having a relatively small collection of built in functions. For any non-trivial JavaScript applications you will probably need a more extensive set of library functions. jQuery provides a small number of utility functions, and in the above example I make use of the grep function it provides. However, libraries such as underscore provide a more extensive set of tools.

The take-home message here is that Silverlight applications have access to a comprehensive set of APIs which can be used to implement view-model logic, whereas with JavaScript you have to find a suitable library or set of libraries to fill the gaps in the JavaScript language. It is unlikely you will find anything quite as rich as the .NET BCL.

So far we have looked at the view-models that define how the user interacts with the quiz application, but we haven’t touched on how these view-models are constructed. If we want our quiz application to be versatile and re-useable it would make sense to externalise the data for a specific quiz.

With the Silverlight application the quiz is defined in XML:

<?xmlversion="1.0"encoding="utf-8"?><quiztitle="Eco-Quiz"><questiontext="How much household waste does each person create a year?"category="rubbish"interestingFacts="That's almost 10 times the weight of an average person. Just think how much waste is created throughout your lifetime ... how can you reduce the 50,000 kg of waste you might leave behind?"><answertext="150 kg"isCorrect="false"/><answertext="513 kg"isCorrect="true"/><answertext="1025 kg"isCorrect="false"/></question><questiontext="How much less energy does it take to make an aluminium can by recycling that creating a new one?"category="cans"interestingFacts="That's an incredible energy saving! The energy saved is enough to power a television for 3 hours."><answertext="10 %"isCorrect="false"/><answertext="40 %"isCorrect="false"/><answertext="95 %"isCorrect="true"/></question><questiontext="True or false: Does a 100 watt bulb produce the same amount of light as two 50 watt bulbs?"category="lightbulb"interestingFacts="Not many people know that 100 watt bulbs are more efficient that 50 watt bulbs and produce more light from the energy the consume, so a simple green tip is to use fewer, higher powered bulbs."><answertext="True"isCorrect="false"/><answertext="False"isCorrect="true"/></question><questiontext="What percentage of the average households electricity bill is from appliances left on standby?"category="washing"interestingFacts="To save the environment ... and save you money ... before you go to bed each night, turn all your appliances off at the wall socket."><answertext="0-2 %"isCorrect="false"/><answertext="8-10 %"isCorrect="true"/><answertext="12-14 %"isCorrect="true"/></question></quiz>

With each view-model being responsible for transforming their corresponding XML elements in to the required property values. For example, the QuizWizardViewModel identifies obtains the quiz title attribute, then constructs a QuestioNViewModel instance from each question element:

Creating the view-models from the XML data is quite straightforward. But how does the end-user of our application supply this XML? Any files we add as resources or embedded resources are compiled within the XAP file or application DLLs, so we need to find some other way of externalising this data.When a Silverlight application is instantiated you can specify a number of input parameters. The

EcoQuiz application expects a ‘data’ parameter which identifies the location of the XML file:

With the Knockout implementation the view-model constructor functions also expect to be passed the configuration data, and again the QuizWizardViewModel sets its title property and creates the question instances:

So with Knockout, how do we create the quiz data that is used to construct our view-models? With JavaScript XML is not the most practical data format, most applications use JSON (JavaScript Object Notation) which has the advantage that it can be parsed directly to construct JavaScript objects. Creating the quiz is as simple as the following:

This makes it quite a bit easier to create a re-useable quiz application where users can supply their own data.

However, in Silverlight’s defence XML is a more ‘robust’ data format, allowing for checks to be added for well-formed or valid documents (if a schema is supplied). Although, this doesn't help with the fact that the interface between Silverlight and HTML / JavaScript (i.e. the hosting page) can feel a bit clumsy.

Silverlight and Knockout have a lot of features in common, and for a Silverlight developer wishing to learn JavaScript development, Knockout is an excellent choice. However, while they share most of the same concepts, the implementation in each is quite different, with Knockout generally being much more concise than the Silverlight equivalent.

Again, I will stress that many of the examples I have given in this article where Knockout is more concise than Silverlight stem from JavaScript, HTML and CSS rather than from the Knockout framework directly.

So … “which is better Knockout or Silverlight?”

Good question! And I am going to dodge that one by saying “it depends”. I am still of the opinion that JavaScript technologies are better suited to simpler applications, whereas Silverlight is more suited to the construction of large-scale enterprise applications (I go into this in much more detail in my article Flex, Silverlight or HTML5 Time to Decide …).

Instead, I’ll give an answer to a slightly simpler question “which is the better technology for a quiz application? Knockout or Silverlight?”

I can confidently state that for the quiz application described in this article Knockout is a much better choice. Despite being a more experienced Silverlight developer, I completed the Knockout implementation in approximately half the time. This is also entirely down to the fact that it is so much simpler.

I would urge any Silverlight developer to learn Knockout. You will not regret it.

I am also a Technical Evangelist at Scott Logic, a provider of bespoke financial software and consultancy for the retail and investment banking, stockbroking, asset management and hedge fund communities.

Thank you very much but i have a question as as beginner to web application programming. As far as i know Silverlight can execute just on client machines which are Windows and Mac with Intel processors. But i think this limitation is not exist for Knockout application. If this is true, it means that my Silverlight application can not useable for smartphones and tablets while using tablets and smartphones are increasing everyday even in industry. Could you help me to find my answers?

I'm silverlight developer also KnockoutJS developer.
I think this comparison completely baseless.
Who can compare javascript vs c# on the other hand html vs xaml?
Html not designed for development in the first place.
In time evolved but that's not enough.
Xaml far more usable than html.
Yes knockoutJS is good tool but javascript too immature for a modern programming language.

If microsoft not abondoned silverlight, maybe I'm never developed with html.
I think developer community forget about html,, javascript and css, and reinvent usable modern technology.

I don't think the comparison is baseless for the very reason that there are developers making the choice between plugin technologies (Silverlight, Flash) and JavaScript technologies (Knockout, Kendo, Angular) on a daily basis. Yes, the two are very different, and the differences between JavaScript and C# couldn't be greater - but this is a choice people have to make!

It is my hope that this article will help people understand these differences, and by choosing Knockout, a Silverlight developer will find much that they are familiar with/

Thank you very much but i have a question as as beginner to web application programming. As far as i know Silverlight can execute just on client machines which are Windows and Mac with Intel processors. But i think this limitation is not exist for Knockout application. If this is true, it means that my Silverlight application can not be used for smartphones and tablets while using tablets and smartphones are increasing everyday even in industry. Could you help me to find my answers?

Excellent article, thanks so much for the solid work. Just a thought: If you desire to use/reuse the XML instead of JSON, you'll find that jQuery parses that nicely, giving you access to each node in the tree.

Yes, you can use XML quite easily within JavaScript applications. Conversely you can use JSON quite easily within Silverlight applications. For simple apps I think JSON is probably the most appropriate format for data in JavaScript apps, no external libraries are required to 'digest' it.

Agreed, where JSON is available, it's in a far better structure for native usage. Data from external systems would be where the XML data would come from, which isn't necessarily relevant to this specific MVVM article. Just good to keep in the back of the mind for those one-offs.

...it's like comparing apples and oranges. If your intention is to give existing Silverlight developers an introduction on similar concepts in JavaScript/Knockout, it's a great article. But if you wanted to determine which framework is better, then IMHO you're not being fair. You're comparing plain Silverlight with JavaScript and Knockout. It would be fairer if you would have included something like Caliburn Micro[^]. And I suspect the comparison might even turn out differently.

In some ways you are right, it is like comparing apples and oranges. However, I think you will find that there are thousands of developers out there who are already trying to make this comparison, apples, oranges and most likely pears too (where a pear is Adobe Flex!).

I guess that you are making the point that Caliburn allows for a more rapid application development, allowing for more rapid view model creation etc ...?

Although, you could counter the argument in that Silverlight is a massive framework compared to JS + Knockout, surely it already has an advantage?

Anyhow, I am not going to make some silly statement like "Knockout is better than Silverlight" - this would be meaningful without context. However, I do stand by my statement that personally I think Knockout is a better technology for the quiz app described in this article. For this reason I think developers need to look beyond Silverlight and learn about the alternatives.

I have used Silverlight for complex LOB applications for customers in the financial domain. In most cases, I believe that it is still the right technology choice.

After seeing knockOut I think any LOB application can be build with Just few HTML pages and add Javascript languages . Then what we followed for any complex project architecture like Silverlight Prism , 3-tier /N-tier architecture like DAL, BAL, Presentation Layer .....nothing important . One thing also is that developer need not to add much more class Library in Solutions , and if need to add I think there is not any value when using KnockOut.js any one can write Model , view and ViewModel everything on single HTML page . Wow....

But one thing we should not forget that JavaScript and JQuery both are very ugly language , if any Javascript function cross 30+ lines than maintaining and understanding becomes little bit problem.

When Silverlight main Problem what if your client don't want to install the plugin in his/her browser , but What if I disable javascript in IE or other browser than same functionality would not be run. Microsoft trying to do better with HTML5 in MVC4, and that is nice because in asp.net aspx page we also used HTML. And wherever we need to add JavaScript for little bit functionality (like showing Pop Up messagebox or warning, open new window etc...) is very well.

But Comparing MVVM pattern with this dirty knockOut is really baseless. This is not MVVM pattern KnockOut made they just modify existing javaScript style after steal the patterns of MVVM.

Problem is Silverlight developers will approach “web” development with or without a MVVM mind set when using Knockout and they’ll create very old style procedural type JavaScript code.
And it's not just a case of using JavaScript OO via prototypes either.

Perhaps they should be using libraries such as Backbone.js and Backbone.CQRS.js
Also, Backbone.Marionette.js if you like a WPF/Silverlight Prism style of composition.
These allow for the building of larger complex JavaScript frontends.
Also throw in a dose of SignalR for good measure

My comment about JavaScript technologies is nothing to do with Knockout or Backbone or any of the other fantastic JavaScript frameworks out there. The comment is leveled at JavaScript itself. I have worked on a large project with 133,000 lines of JavaScript code. I can tell you from experience, that this is a maintenance nightmare!

Excellent article and timely too.
I am on the journey from Silverlight 5 to HTML5 and I am trying to decide when to use which technology.
Knockout and Upshot as part of MVC4 are looking like a good way forward.

It's a shame Microsoft have just junked Silverlight and destroyed all confidence in it.
As a result, my company are buying 150 iPads and will not go Windows 8 whatever it does.