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

Question

I was wondering what would be a good approach (or recommended approach) for partial viewing in a web application.

I have a requirement when I need to upload data to an already processed page using AJAX, sort of like the "Download more ..." link at the end of the page, which captures additional information from the server and transfers it to the bottom of the page.

Two options I'm currently playing with are for the AJAX answer:

• Returns a JSON representation of the data and uses a client-side template library (e.g. jQuery templates) or just javascript to turn JSON into HTML and add to the bottom of the page
• Note the partial view on the server (in my case using grails render template:'tmplt_name' ) and send it by wire and just add the result to the bottom of the page

Are there any other ways to do this? If not, then, given the above options, which would be better in terms of service, performance, and verification? One thing is for sure, the JSON route (in most cases) will use less bandwidth than sending html via wire.

Answer 1

This is actually a really interesting question, because it offers some interesting design solutions.

I prefer rendering partial templates because it gives my applications the ability to change over time. If I need to change from <table> to <div> using a chart, it is easy to encapsulate this in a template. With that in mind, I see almost every page as a collection of many small templates that can change. Grails 2.0 graphical scaffolding is a good fit for this type of approach, and that's a good idea.

The question of whether they should be client templates or server ones is a major issue.

Server-side templates retain markup cleanup on page load. Even if you use something like Mustache ICanHazJS , you just need to have an empty element on the page (something with your template), properly configure it and work with it in Javascript to update your information.

disadvantages

• "chatty" applications
• large envelopes over the wire (responses include HTML that can be considered static)
• slow user interface response time

Benefits

• Good for people with lots of server side experience.
• It may be easier to manipulate or modify in a server environment (for example, returning a page embedded in several templates that are programmatically loaded and included)
• Saves most of the material in one place

However, client templates can actually reduce server load. They make the application "less -chatty" because you can potentially minimize the number of server calls by sending larger JSON collections back (in the same number of bytes or less that HTML will process to the server-side server schema). They also make the user interface very fast for users, as clicking on the update link does not have to do AJAX round-trip. Some said:

Anthony Eden @aeden 10 Dec Reply Retweets Favorites · The future of web applications is open: requests are processed by functions, logic is always asynchronous, and HTML is never generated on the server.

disadvantages

• Not very suitable for SEO (non-semantic extraneous user interface elements when loading the page)
• Requires Javascript foo (for managing items)

Benefits - Responsive - Smaller Envelopes

Trends seem to move toward client-side patterns, especially with the power provided by HTML5 add-ons (like <canvas> ) ... but if you need to use them, you must rely on technologies that you are not very familiar with, and you Feel more comfortable with Grails particles, it might be worth starting with them and exploring refactoring towards client templates depending on performance and other issues later.

Answer 2

in my opinion, the second option of partial rendering is better, because if you get json data that you must manipulate it as a given style, create elements, set values ​​and a similar thing, like the need immediately after you get ajax response in javascript, but if you do partial, you can design your view in partial before and continue ready and simply import using an ajax call, so there is no responsibility for processing the response data.

Answer 3

I would say it depends on how much data you send over the wires, as you put it. If you implement the “download more” function, then it seems that you do not want to take 5 seconds to download something. Google Images are a good example of how fast this feature should be. If you know that you will never have such a large amount of data, then providing partial data on the server may be cleaner, but if you change the requirements, then it will be difficult for you to return to the first approach. In short, I would say that the first approach allows more control over natural disasters, how long it takes to load a large load for a large amount of data. I would say that it is also a good practice when you can abandon the server, even if it is a little inconvenient on the client side for the developer.