jQuery Templates vs Partial Views in ASP.NET MVC

Question

I'm taking a look at jQuery templates. It looks really interesting - easy syntax, easy to use, very clean.

However, I can't really see why it's better to use jQuery templates instead of simply fetching partial views via AJAX. It simply seems like the partial views would be much easier to maintain and helps to avoid duplication of code.

I want to use jQuery templates. But when would it be better than partial views?

Answer 1

I agree that these do overlap. There are several different ways to implement the same piece of software, and much of your decision on what to use depends on your personal preference and the context of your software.

Partial view advantages:

• Type-safe (if using strongly-typed viewmodels)
• Allows static syntax and type checking.
• Full code completion / syntax highlighting support in Visual Studio

jQuery Templates advantages:

• Allows the page to be updated before performing postbacks or without any postbacks to the server side at all. This can be handy when creating heavily ajaxed interfaces, possibly also with html5-driven offline capabilities.
• You can retrieve data from the server in JSON format and render that to HTML. JSON is much shorter that HTML formatting, so this can make a difference in page loading times for long lists of data entries when using a slow internet connection.

So in essence partial views are the more stable and jquery templates are (for ajax websites) the more performant choice. I therefore use partial views for less frequented web pages which need to be developed quickly and jQuery templates for heavily ajaxed web pages where performance really matters.

Answer 2

One example is when you want to display a number of rows initially, but then also add/remove single rows over the course of the page view (think displaying and then editing an invoice document). Having the granular control to be able to render a single row at a time gives you the ability to significantly improve the responsiveness of your app.

Answer 3

i would add that one of the benefits of the jqt is that you can very easily pass the front end development off to a 3rd party (who specialise in this type of work) and they only need to know the object model of the json. (plus maybe a few 'interfaces' back to the server)

this way, your 'backend' developers can focus on the task at hand and the 'front' end team can develop the jqt. the other advantage of jqt being that they are totally isolated from the .net environment, therefore it's feasible (if unlikely) that the backend technology could be changed (j2ee, php etc) for a subset of actions without the front-end caring beyond the rest url.

it's an interesting 'space' to observe and one that i'm only just beginning to dabble with. however, on both sides of the fence, things will only get better and as i mentioned to dave (ward) a few weeks back, perhaps some of the razor engine endpoints will offer a way to integrate directly with jqt in future versions - seems kinda inevitable.