Question

I was wondering what would be a good approach (or recommended approach) to render partial views in a web application.

I have a requirement where I need to load data into an already rendered page using AJAX, sort of like a “Load more…” link at the end of the page which grabs more information from the server and renders it to the bottom of the page.

The two options I am playing with at the moment for the AJAX response are

1. Return a JSON representation of the data, and use a client side template library, (e.g. jQuery templates) or just plain javascript to turn the JSON into HTML and append to the bottom of the page
2. Render the partial view on the server (in my case using grails’ render template:'tmplt_name') and send it across the wire and just append the result to the bottom of the page

Are there other ways to do this? If not, given the above options which would be better in terms of maintenance, performance and testability? One thing I am certain about is that the JSON route will (in most cases) use up less bandwidth than sending html across the wire.

Answer 1

This is actually a really interesting question, because it exposes some interesting design decisions.

I prefer rendering partial templates because it gives my applications the ability to change with time. If I need to change from a <table> to a <div> with a chart, it’s easy to encapsulate that in a template. With that in mind, I view almost every page as a aggregate of many small templates, which could change. Grails 2.0 default scaffolding has moved towards this type of approach, and it’s a good idea.

The question as to whether they should be client-side templates or server-side is the crux of the issue.

Server side templates keep your markup cleaner on initial page load. Even if you use something like Mustache of ICanHazJS, you kinda sorta need to have an empty element in the page (something with your template), style it appropriately, and work with it in Javascript in order to get update your info.

Drawbacks

• “chatty” applications
• larger envelopes across the wire (responses include HTML, which may be considered static)
• slower UI response time

Benefits

• Good for people with lots of server side language experience
• Maybe easier to manipulate or modify in a server-side environment (e.g. return a page embedded with multiple templates, which are programmatically loaded and included)
• Keeps most of the application stuff “in one place”

Client-side templates can really reduce server-load, however. They make an application “less -chatty”, in that potentially you could minimize the number of calls back to the server by sending larger collections of JSON back (in the same number of bytes, or fewer, that would be taken up by HTML in a server-side template scheme). They also make UI experience really fast for users, as clicking an “update” link doesn’t have to do an AJAX round trip. Some have said:

Anthony Eden @aeden 10 Dec Reply Retweeted Favorite · Open
the future of web apps: requests are handled by functions, logic is always asynchronous, and HTML is never generated on the server.

Drawbacks

• Not great for SEO (un-semantic extraneous UI elements on initial page load)
• Requires some Javascript foo (to manipulate elements)

Benefits
– Responsive
– Smaller envelopes

Trends seem to be moving towards client side templates, especially with the power exposed by HTML5 additions (like <canvas>)…but if leveraging them requires you to rely on technologies you’re not extremely familiar with, and you feel more comfortable with Grails partials, it may be worthwhile to start with those and investigate refactoring towards client side templates based on performance and other concerns later.