Why use Knockout JS?

[Halis]

If I'm using ASP.NET MVC 3 on a project, why would I need to use
Knockout? The razor view engine does a pretty good job with
@Html.TextBoxFor etc etc

[FranWahl]

Razor and knockout are completly different things.

A more logical question would be why use knockout if you got JQuery.
You can find more details on knockout and similar frameworks here:
http://knockoutjs.com/documentation/introduction.html

You propably should also go to http://learn.knockoutjs.com first and
check out the online tutorials.

[Diego Guidi]

You should read something about Model-View-ViewModel pattern. 

Basically, if you wanna build a fast web app that is heavily based on client operations (i.e: a jquery mobile "static page" with all behavior based on ajax calls that send and returns json) you need to use knockout, or any other library that helps on MVVM. 

my2cents

[Halis]

I'm not saying Knockout and Razor are the same thing. I'm saying that
when I use HTML helpers such as Html.EditorFor in the Razor view
engine, I can bind to my model automatically (and with strongly typed
intellisense). If that is the end result that I get, how does that
differ from the end result you get when using Knockout?

So, let me refine my question a bit.

If I have ASP.NET MVC available to me, what is a complex client-side
UI scenario where using Knockout JS would be preferable to using Html
helpers that bind to the model? What are the benefits to using KO vs
what I'm talking about? Are there any?

Disclaimer: Broad generalizations in lieu of actual knowledge are
strictly prohibited!
The following is a list of abstractions already known to me:
1) It depends
2) It depends on the project
3) It's a matter of preference
4) There's no one/right way to do things

[Mark]

"If I have ASP.NET MVC available to me, what is a complex client-side
UI scenario where using Knockout JS would be preferable to using Html
helpers that bind to the model?"

 

Disclaimer: I might be misunderstanding your query, because the answer to this seems to be satisfied by simply falling back on the fact that these two technologies are employed at two diametrically opposing levels of the presentation stack.

 

That said, a satisfactory answer to the above question would seem to be: a complex client-side UI scenario where using Knockout JS would be preferable to using Html helpers that bind to the model is any such scenario where Javascript/DOM/jQuery/AJAX would also be preferable to using Html helpers that bind to the model.

 

That is to say that, the benefits are the same as those afforded to you by taking an client-centric AJAX approach to developing a web application vs. a traditional server-side approach.

 

To elaborate, the answer to your second question:

 

"What are the benefits to using KO vs what I'm talking about?"

 

would be: The benefits of using KO vs what you are talking about is that by using KO you can avoid putting presentation logic on the server, and avoid bloating up your HTTP dialogue with presentation logic and markup, while not giving up one of the primary benefits of MVC - separation of concerns .  I suppose one drawback might be that you now have to expose your data layer through some other mechnism in addtion to MVC, such as an OData Service layer (perhaps using WCF Data Services).  However, if you are willing to give up MVC altogether (and I am not saying you should), that drawback goes away.

 

[Craig Beck]

KO is best suited for ajax heavy applications where the page has been rendered where you cannot use Razor to dynamically manipulate the DOM etc.. i.e. Razor is "bound" on the server side, and does nice things for forms etc. by creating static markup that makes development easier; KO is bound to the DOM client-side and is really good at rendering page elements dynamically based on ajax calls, as well as making binding to other page elements trivial (i.e. binding a text box to a live-updating preview)

I'm currently using KO to build a ajax heavy site built with ASP.Net MVC3 and KO is awesome for what I need.

-- 
Craig Beck

http://bonzalabs.com

[Mark]

@Craig Beck

 

I am curious, since you are building an "ajax heavy site", what do you see as the benefits to sticking with ASP.NET MVC vs. just going to a full-bore "thin-server" approach (i.e. no presentation logic on the server).  I ask this partly because I am about to start a new project and have decided to go with a full ajax implementation.

 

I don't mean to hijack or derail the thread, but I think your answer to my question may very well help the OP get a clearer picture of what KO delivers, even though he, like your, appears to be committed to remain dependent upon ASP.NET MVC.

[Craig Beck]

I didn't make the architecture decision (that happened long before I got there), but ASP.Net MVC was chosen as the framework for building an OData service designed to serve HTML, plain json, as well as the OData flavors of atom and json. 

Basically any one route doesn't actually do enough for a UI i.e. they are very fine-grained and you wouldn't want a user to have to navigate dozens of uris to get anything done so the HTML served is really a consolidation of several routes into a usable UI all done through ajax and KO on the client side.

Does that help?

-- 
Craig Beck

http://bonzalabs.com

[Sinisa]

Im a probably very strange asp.net user.
I use asp.net only with JScript, so json works by default.
On the server side I handle images and json, on the client side only pure html and jquery, ko etc.

My client and server side are totaly disconnected, except cookies, sessions...

For me, asp.net is overkill to do something. Creating class to put something in database and getting it back.. nope :)


but, thats me

[Michael Latta]

The value of a server side framework/technology is that you can ensure business rules are applied, and security is enforced in an environment you have more control over. Doing all the app presentation logic in the server is going the way of the dodo, but business rule enforcement and security still belong there. Even for in-houes apps or ones all behind the firewall the server should never trust the client. The server should still do full validations of all inputs and updates, and still enforce any logic requirements in terms of workflow and sequencing of events. The main point is where is the point of integration. It used to be the database so databases added referential integrity and other validation features. Now, it is mostly the web service, so those need to do the validation and security.

Michael

[Halis]

Thanks for the replies, hijack my thread anytime if you can teach me
something useful.

[Jocke]

Sent from my iPhone

[Mark]

Thanks for the reply, I think I see what you are saying. Although, I
am not sure I can conceptualize what benefits you are reaping by
building an OData service around MVC, rather than just using WCF Data
Services.

As for the UI, it sounds like you are composing views into a page on
the server, which I can see being a very useful feature if you don't
need/want the full SPA (Single Page Application) experience. I am
composing my UI on the client instead, so I have a bit more glue logic
living on the client (written in JavaScript).

I will say that I am glad that Microsoft decided to break out the
routing classes from MVC - I am using those to provide nice REST-style
URI access to my view/viewmodel heirarchy.

On Feb 13, 3:49 pm, Craig Beck <craig.b...@bonzalabs.com> wrote:
> I didn't make the architecture decision (that happened long before I got there), but ASP.Net MVC was chosen as the framework for building an OData service designed to serve HTML, plain json, as well as the OData flavors of atom and json.
>
> Basically any one route doesn't actually do enough for a UI i.e. they are very fine-grained and you wouldn't want a user to have to navigate dozens of uris to get anything done so the HTML served is really a consolidation of several routes into a usable UI all done through ajax and KO on the client side.
>
> Does that help?
>
> --

> Craig Beckhttp://bonzalabs.com

[Ravi Kumar]

Hi,

Some of the major reasons why knockoutjs is used for as follows :-

1. It detect the data changes in data model and updates respective part of the UI. For example showing custom messages.
   
2. Binding data and UI declaratively. In other words declarative binding between data model and UI can be done using knockout.js
   
3. Creating custom behavior by using Computed observable.
   
4. It helps to create complex dynamic UI using declarative bindings. 
   
5. It helps to edit JSON data on the JavaScript UI.
   

For more please visit here

Thanks

Ravi Kumar