Render partial view on the server or send json data and render template on the client

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.

Slumgullion

I would suspect that you are already rendering similar content on the user's first contact with the page, as you intend to do with the "load more link". Would it not make sense to load what is loading after clicking "load more" in the same way and reuse the code you've already written for that? Your question is interesting and I'd like to see what your thoughts and those of others on the topic are – Cara

Yes, on first interaction I am re-using the same template (in point 2) to render the complete page (with the other static sections of the page). Both options work for me, and I've used them both in a scattered matter. I'd be interested to see the thoughts of others on this as well. – Slumgullion

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.

Lambrequin

Answer 2

in my view the second option rendering partial is better because if you get a json data you are supposed to manipulate it like set style, create elements, set values and similar thing as per the need just after you get ajax response in javascript but if you render partial, you can design your view in that partial before and keep ready and just import using ajax call so there is no responsibility of handling the response data.

Corse

Answer 3

I would say it depends on how much data you're sending across the wire as you put it. If you're implementing a "load more" feature then it seems like you wouldn't want to take 5 seconds to load something. Google images is a good example of how quick that feature should be. If you know you'll never have that much data then rendering the partial on the server might be cleaner, but if you're requirements change then it's a hassle to go back to the first approach. So in short, I'd say the first approach allows for more disaster control as far as how long a load more takes to load a large amount of data. I'd say it's also general good practice to take load off server when you can, even if it's a little inconvenient on the client side for the developer.

Happ

The data is mostly simple textual values for some water treatment samples. The load more basically grabs some complementary historic data that is not very relevant to load on first interaction unless the user needs it. wrt to taking load off the server, I think with proper caching of the partial template this should not be an issue no? – Slumgullion