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, (eg 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 (eg 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.

Answer 2

在我的视图中，第二个选项呈现部分更好，因为如果你得到一个json数据，你应该像设置样式一样操作它，创建元素，设置值和类似的东西，只需在javascript中获得ajax响应后，但如果你渲染局部，你可以在之前设计你的视图并保持准备就绪，只需使用ajax调用导入，这样就没有责任处理响应数据了。

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.