Moving from traditional ASP. NET MVC to WebApi + Knockout

Question

I've just read an interesting article about how Microsoft seems to be moving towards a REST interface + client-side javascript-based MVVM development for web applications.

Although I technically understand the basic difference between the two models, I am utterly confused regarding its implications about how I write web applications and most importantly how to transition gracefully to this new model.

So, for someone moving from traditional ASP.NET MVC to WebApi + KO, the following questions arise:

• Is there a way to have unobtrusive or near-unobtrusive (i.e. minimal code) validation using MVC + KO?
• How does one go about unit testing his UI code?
• Does browser compatibility suffer with KO?
• Is there anything else someone has to consider when moving from one model to the other?

Answer 1

You see Microsoft starting to push this "single page web app" thing partly because it can provide a better user experience but largely because it makes it much much easier to migrate your web app to being a Windows 8 native application.

Re: unobtrusive javascript for validation… I would say that if you're using Knockout, you're UI and your scripts are going to be so tightly coupled even just for basic stuff that unobtrusiveness is really not a valid goal. You can do validation in Knockout (see https://github.com/ericmbarnard/Knockout-Validation#readme for example) but it's not unobtrusive by the same definition as ASP.NET MVC

Re: unit testing... take a look at https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit

Re: browser compat... I'm not aware of any compatibility issues with any modern browsers unless you have crazy users who have disabled JavaScript

Answer 2

I found this to be a really nice discussion of the pros and cons of trying to be "unobtrusive" with a Knockout site.

Traditionally I'm very much in favour of keeping Javascript as unobtrusive as possible, and with my Knockout expressions I try to keep them as minimal and tidy as possible by shifting any heavy lifting into functions on my view model and creating custom bindings which encapsulate DOM logic - but I'm firmly of the opinion that the declarative approach itself (such as the default of using the data-bind attribute), when used sensibly, is the way to go.

Perhaps it's because my introduction to Knockout is a web application "port" of a WPF application I worked on, and the Knockout bindings of my site are becoming surprisingly close to their XAML equivalents as I learn more about how to leverage Knockout gracefully. I just love being able to eyeball markup and see at a glance the real business logic around how a view is evaluated, rather than the specifics of how jQuery or whatever physically builds it in response to some click event wired up in a big soul destroying Javascript file.

When I revisit some of my traditional MVC sites which leverage lots of procedural jQuery to hook things up, I think, yeah the markup is tidy, but going back to it after 6 months even I have difficulty understanding what my intention was with all those jQuery selectors, callbacks, and DOM traversals. I think I would only apply the Knockout bindings themselves dynamically if I had to, i.e. if there was a situation where my binding logic was itself dynamic - but that could probably be accomplished differently with dynamic templates anyway.

That's my 2 cents on the unobtrusive aspect of your question, and if your experience moving to MVVM Javascript is anything like mine has been over the last few months, you won't look back.