Does it make sense to integrate backbone.js with ASPNET MVC?

I'm not an expert in these building blocks, but at first glance it seems to me:

• ASPNET MVC wants to generate the views and manage the models for an app on the server side. It views the browser as a somewhat dumb presentation engine, a consumer of the views that are provided for it by the server.

• backbone.js would like to generate the views and manage the models in the browser. It views the server-side as a fairly dumb REST-based persistence engine.

This seems like a simplistic view. I'm sure it's not the whole story.

What are the real opportunities for integrating these two things? Does it make sense to do it? Or is there too much overlap between them for it to make sense?

I like to see some analysis or discussion of this, if anyone can refer me.

Whilst I cannot speak to backbone.js, I can tell you that I've used knockout to great effect combined with ASP.NET MVC. Every ASP.NET application that I've seen to date uses a mix of client-side and server-side view generation. There is always going to be times where its more convenient to generate views server-side. Take for example conditional UI elements based on whether or not a user is authenticated, or whether they have a specific permission. You may not want a web savvy user to be able to explore your client side templates and work out all the features they're not getting. Sure you could get around this by asynchronously loading different client templates, blah blah, or wind up writing server-side code to generate your client-side templates... Furthermore if SEO means anything to you, you can kiss client-side templating (by itself) goodbye.

So the sweet spot, in my opinion, is something that does both well. In my experience I have found ASP.NET MVC to excel at both.

Why ASP.NET MVC is awesome

• Layouts (MasterPages)
• Razor (type-safe views with intellisense goodness)
• ActionFilters (awesome spot for applying conventions like logging, auth, etc)
• JSON serialisation for free - return Json(model)
• Model-binding and validation
• IoC and MVC are best friends (win)
• Authentication + authorization
• Lots of other stuff that I can't think of.

By using a client-side framework for view generation really all you're missing out on is Razor. You can even leverage layouts to some degree.

The approach that I take to development with ASP.NET MVC is to start by making the application work server-side. This forces you to think about you want your URL structure, what deserves a controller, what your routes should be. It also means you get the benefit of type-safety and auto-complete during the first iteration of views. At the end of this exercise you've got a simple, standards compliant solution (hopefully) that works on any device known to man, that Google can't get enough of.

I then set about taking an incremental approach to implementing slices of client-side functionality. On the client side I write some javascript to hijack a request that I want to turn into an AJAX request, and handle the response using a translated version of the Razor view. On the server side I take a convention-based approach using an action filter. This action filter does approximately the following:

• Is the ActionResult a ViewResult?
  • What is the Accept type?
    • HTML - Return a PartialViewResult of the same name prefixed with "_" given the same model
    • JSON - Return a JsonResult given the same model
• Is the ActionResult a RedirectToRoute result?
  • Return EmptyResult (or optionally you could return the URL in a JsonResult)

With this approach you can add AJAX functionality without changing a single line of code in controllers. An alternative approach is to follow the Thunderdome Principal and have an ActionInvoker responsible for wrapping the model in an appropriate result type based on the request context. I haven't worked out how server side navigation (redirects) fit with this approach though.

The waste in starting with a server-side implementation is you're doubling up in view generation code (Razor + js-based template). Depending on how much of your application you want to implement at the client, this may or may not be a problem. Spark is the exception to this in that you can actually get it to generate client templates for you! The downside to Spark is that you lose intellisense (there's a plugin for it but its crap) which is not an insignificant loss, plus I just prefer Razor (its baked in, doesnt need to be configured, and isn't going away any time soon).

I have used asp.net mvc KO and bakcbone for different projects and it all comes down to nature of project in the end. Server stack won't go out of the box once your workflows start getting complex or you are to offer UX unlike simple data data centric applications. When your project involves great UX backbonejs can get you there.. Downside is that there are no well defined centralized guidelines for that you will have to go through hell of blogs to get things done .. For conventional apps you can stick to KO. Btw there are plugins that can mock KO for backbonejs .. I'm referring to bacjbone.modelbinder again you need to integrate for your self Cuz MS won't bother at all.