http://ejohn.org/blog/javascript-micro-templating/ is a devilishly brilliant hack for this. End result is very clean.

I too prefer a JSON response with client-side HTML creation logic.

Unfortunately, most real-world client-side HTML writing scripts are broken, containing many HTML-injection flaws that can easily become cross-site-scripting security holes. I think the belief is that because you re talking to your own server rather than directly to a hostile user you re somehow ‘safe’ and can get away without correctly strings when interpolating them into HTML. Which is of course nonsense.

I always see stuff like:

$( #mydiv ).append( <em>Deleted  +response.title+ !</em> );

or:

mydiv.innerHTML=  <p>Renamed to  +response.name+ </p>;

or indeed Resig s microtemplating hack, where there is no HTML-escaping done by default. Come on, people! We ve only just started cleaning up the legacy of broken PHP scripts serving up server-side XSS, now you want to introduce a whole new massive range of client-side XSS exploits?

Sigh. That s the Lure Of Strings. We think we understand them and can sling them together willy-nilly. But strings are treacherous, with hidden contexts and escaping requirements. If you must generate HTML on the client side you will need a function like this:

function h(s) {
    return s.split( & ).join( &amp; ).split( < ).join( &lt; ).split( " ).join( &quot; );
}

mydiv.innerHTML=  <p>Renamed to  +h(response.name)+ </p>;

But personally I prefer DOM methods. Like with parameterisation for SQL, using the DOM methods takes the string-slinging out of the equation by talking raw strings directly to the components that will consume them. OK, the problem with the DOM is that it s rather verbose:

var p= document.createElement( p );
p.appendChild(document.createTextNode( Renamed to  +response.name))
mydiv.appendChild(p);

But you can always define helper functions to cut down on that, eg.:

mydiv.appendChild(makeElement( p , {},  Renamed to +response.name));

(The new element creation stuff in jQuery 1.4 uses a similar style.)

+1 year ago, we started a new web app, and needed a way to render HTML from JSON data, in the browser.
We wanted it as fast as an XML/XSLT transformation.

Our answer to that was the JS template engine PURE.

Unlike most of the JS templating libs around, it keeps the HTML untouched(no strange tags at all) and except a few notations, it doesn t bring a new language to learn, only JS and HTML.

The way I use it:

• Build the static HTML directly in the page
• Then add the JS logic step by step, and the HTML becomes alive progressively
• Once you get used to it, both HTML and JS can have a safe separate development life, and can be split between a designer and a JS developer job

We had a system where a lot of data was being passed as JSON from the server and then handled through a javascript templating engine on the client side. In .Net 4.0 (maybe even 3.5 sp1, i am not sure), this can be done using Client Templates.

I would prefer passing JSON over sending html. Its always good to keep data and view separate.

If you want to preserve the MVC framework, you should let your template framework do the templating. The AJAX should only perform the server request, which performs all DB and business logic and then returns the URL to the template that should be loaded.