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

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?

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.

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.

I find Tyrsius' answer a bit too negative. Knockout MVC is still in early development, but from what I can see it has some advantages and is less server heavy than Webforms for example. Visiblity dependancies get handles entirely on the client, only when using functions a call is done to the server. When working with complex data structures, it sometimes is required to go via the server anyways, so then Knockout MVC might be a good way to save on writing a lot of Ajax-handling yourself.

It is true it always sends the entire model back and forth, which gives some overhead as opposed to building it yourself. But I wouldn't write it off entirely. Especially when it gets proper client-side handling for complex validations in the future.

I've come across this post after searching a bit about knockout mvc. Although I agree with the waste of network bandwidth, I'm quite seduced by that line of code :

@{
  var ko = Html.CreateKnockoutContext();
 }

This is a neat and clean way for generating the knockout viewmodel. Has anyone used knockout MVC just for that feature and without moving all the logic to the server side ?

The beauty of Knockout.js is that you can get your application served by simply passing JSON back and forth from the server without having to push an entire view that the server had to chunk away at to generate HTML.

It seems very counter-intuitive to put that back on the server again! If that interests you, you're better off using the razor syntax to accomplish your binding in the first place.

My suggestion would be to use knockout.js to do your binding so that the binding takes place on the client rather than the server if this is the goal you're going for. If you want your view to be data bound on the server, use razor.

More, knockout.js sure is very good at client side data display/delete/insert/update, and client side data calculation. If a real business logic is as simple as that, we must apply knockout.js directly.

The truth is, business logic is not always simple like that. For example, when client insert a new record on view, system possibly need to check User's authentication, set default values for the new created object based on some business logic or formula etc... All this, anyway should go to server side and checking logic based on database data.

Developer is able to translate all required business logic into java script methods inside knockout.js view model. But this way, the design violate the rule of handling business logic centralized.

The maintain will become nightmare for such design.

Summary, what framework choice really depend on business requirement. Sometime, performance is not the first consideration.

I can also see a lot of good use-cases with Knockout MVC library. I could hardly integrate KnockoutJS into our MVC web app, exactly because of reasons which were pointed out by for example @ChinaHelloWorld. Here are some cases where I find it extremely helpful.

1. Strongly-typed bindings

I liked the nice strongly-typed HTML helpers methods, which became completely useless and messy when it came to setting up KnockoutJS. The best thing I could do is to manually attach my binding attributes with the extra parameter of the helper methods, but I had to use magic strings there again. I like the helpers provided by Knockout MVC for creating inputs and other elements with strongly-typed, C# expression based bindings. However, here I would like to mention that I miss the name attribute of the generated fields, so I needed to tweak it a little.

2. Strongly-typed binding syntax (kind of)

When using pure string bindings, there is always a good chance of misspelling, or not exactly knowing the correct format of the binding which you'd like to apply. With the fluent API of Knockout MVC and the VS IntelliSense it's really easy to apply the correct bindings.

3. (Almost) Automatic conversion from computed C# properties to computed bindings

Just with application of the small [Computed] attribute, Knockout MVC can generate the corresponding binding expression in correct KnockoutJS syntax. This one is very useful as well I think.

4. No viewmodel code duplication

In the classic way, I needed to have the viewmodel class in C# code, and then (nearly) the same viewmodel code in JS (with observables). Well, THAT was frustrating for me, and I got extremely happy when I saw the technique used in Knockout MVC. However, I needed to tweak it a bit for being able to use it with really complex viewmodels (nested viewmodels, collections, etc.), and to be able to extend the mapped Knockout viewmodels with for example any needed custom JS method or computed observable.

So here are at least four very good points. And about viewmodel round-trips: no-one told that anyone of us need to use the server-side processing mechanism of Knockout MVC. I wouldn't use that either, only if there is some complex business logic which really needs to be processed on the server. But in most cases, Knockout MVC is just for simplifying the binding and setup process of MVC Views and KnockoutJS. So I don't quite understand the bad opinions above. I think who wrote these opinions did not take the effort to learn at least the basic concepts of Knockout MVC. Yout definetely should NOT use Knockout MVC instead of KnockoutJS, but besides KnockoutJS. Understanding Javascript and at least the basics of KnockoutJS is still mandatory in any case.

I wish the author continued the development of Knockout MVC, because besides these good points, there are some features and refinement which would really make it even more powerful.

In .Net MVC pattern, view model already marking into each view/partial view clearly with tag "@model yourmodel", which can guide developer to understand what will do in this view.

When using knockout.js MVVM pattern, you possibly would not see any .Net view model, except tags like "data-bind" in the views. This would make the view and controller uncoupled and difficult to track logic specially for a new developer in a team.

I believe knockoutMVC can solve such difficulties and saving a lot of javascript codes which will make the system difficult to maintain and understand.

Since knockoutMVC makes the design still stick on applying server-side view model which is easy to track and maintain since it is the C# code.

For a business project, manager should always focus on easy to develop, easy to maintain, easy to upgrade and easy to understand and quickly delivered to make money.

Sacrifice a little bit of performance but make it simple, consistency at client-side and server-side should be a key point. Javascript is a big maintenance issue.

Does it really a matter sending back the whole view model back to server-side? If it does, we can split a big model to several small models.

You still have the performance if you are not using functions generated by komvc. As Nigel said, the initial page generation would still have to be server generated. You can always add user scripts and create functions on the client side that won't need to go back to the server. It's a tool that gives the developer a bit of productivity. The comparison with web forms on performance is sure exaggerated. Folks, that's one tool that sure helps you meet your deadline.

I will add my 2 cents in favour of knockoutjs, though it is little complicated to write compared to knockout MVC, the benefit you get is huge when it comes to re-usability. The client code can work harmoniously with other technologies as well.

Keeping aside the security perspective I personally feel knockout js is a way of complicating asp.net MVC and it should be used as is (knockout js) with pure RESTful applications such as asp.net webapi.

Knockout MVC is a powerful extension for ASP .NET MVC that allows you to implement the website client functionality directly on your .NET project using developer friendly fluentAPIs without Javascript and removing a lot of duplicated and repetitive code.
knockout MVC is the same as coding ASP .NET MVC razor and you get the client functionality without any extra hassle.
You won't have to code a view model and lines of binding code.
I have been using koMVC on most of my websites and the develop time reduction, easy maintenance and mininal learning curve are a huge payoff.
I suggest you check their website and have a go with some live examples. http://knockoutmvc.com<br/> It wont take long for you to fall in love with it.

MVC is an architecture pattern which separate into three component, Model, View and Controller.

KnockoutJS work best with the MVC architecture because the framework’s data binding require the use of controller. There are frameworks such as AngularJS which focuses more on the front end and therefore they work better with the MVVM architecture pattern (model, view, view model). Their data binding features also doesn’t require the use of controller which reduce the scope of binding.