Is there a reason I would use Knockout MVC instead of Knockout JS?

Question

Another user suggested Knockout MVC to handle some AJAX posting issues. I read a little on it and I see it is a wrapper around Knockout JS. So I wonder what are the real differences between the two? Should I bother with Knockout JS since Knockout MVC exists? When would I use one over the other?

Answer 1

Knockout MVC is the bastard child of WebForms. It routes all viewmodel methods through controller actions, meaning everything that happens has to bounce to the server and back. I cannot understand why anyone would take a framework like knockout, which is intended to be CLIENT SIDE MVVM, and force it to call the server for every function.

In addition, performing those methods on the server means the entire viewmodel needs to be passed to the server, and back to the client, for every function call. This is incredibly wasteful.

Using Knockout MVC means sacrificing all the performance benefits of client-side code for the benefit of not having to write javascript. The same trade-off WebForms made. It is not a good one. It is an antipattern.

If Knockout MVC dies tomorrow, the web will be a better place.

Answer 2

I just ran across this question which has some pretty negative responses. I'm going to quickly add my two cents worth.

I have only just started using KnockoutJS. Since I'm building ASP.NET MVC apps, it seemed logical to me to use something like Knockout MVC. For the most part, it seems like a great idea. I don't want to be spending time writing javascript and <!-- ko --> comments through my pages if I can do the same using .Net functionality that I know and love.

Having said that... yes, there are limitations to KMVC at the moment. Sending the entire model back to the server is a big one. So what I've done is started my own fork of knockout-mvc. The changes have been necessarily rushed at the moment. But I now have ability to:

• create sub-contexts (with completely different models or components of the view model)
• pass selected portions of model back when calling the server
• expect a different model back from a call than what was sent
• fire events around the ajax calls
• support more html5 input types
• pass anti forgery tokens to the server via headers (for ajax calls)
• probably more I've forgotten

I'm hoping to get back soon and really clean up what I've done. Hopefully, the author will include these changes in his code. If not, I guess I'll keep my own fork going. Either way, there's light at the end of the tunnel. KMVC might need work as it stands, but I believe the concept was definitely worth doing.

I definitely think

If Knockout MVC dies tomorrow, the web will be a better place.

was a bit harsh.

Edit:

I was looking at the comments and looked again at what the original question was. Having done that I think a little bit more should be added to my answer:

First, the original question was Is there a reason I would use Knockout MVC instead of Knockout JS? To answer/clarify (maybe I'm just being picky) that: Knockout MVC is a framework designed to make it easier to integrate KnockoutJS with your ASP.NET MVC app. It does this mostly by using familiar, strongly-typed constructs to generate KnockoutJS tags. It is not a replacement for KnockoutJS. By all means use KnockoutJS. The question is really whether to use Knockout MVC as well.

Having said that, the choice is still yours as a developer to choose when to use various aspects of all the tools available to you. If you want to handle a certain aspect of functionality by performing a full request back to the server, then do that. If you want to perform an ajax request to retrieve/update data, then do that. If you want to perform functionality purely client-side, then do that.

Using Knockout MVC does not prevent you from utilising KnockoutJS to it's fullest. Using Knockout MVC does not prevent you from writing additional javascript to handle as much client-side functionality as you want. Just because Knockout MVC provides you with a short-cut to generate ajax callbacks to the server does not mean you have to use them. Although, if you application ever persists data, it's going to have to call home at some point.

There are reasons for building an application backend using ASP.NET MVC compared to just using Apache to serve static HTML and script files. Knockout MVC allows you to continue to take advantage of those same benefits to assist with KnockoutJS integration.