Best practice: loading rendered html or json?

Question

Hey folks, I have a question which feels stupid but I can't quite say why.

Background:

Imagine a webapp with users and tags. Users tag each other.

I've got one page in the app which displays details about a single tag in relation to a single user. Let's say user 'bob' and tag 'footag'. On this page, I'm displaying two lists: all the people who have tagged bob with 'footag' and all the people bob has tagged 'footag'. let's call these <div id="received'> and <div id="sent">

Let's say the url for this view is /users/bob/tags/footag

Naturally, these lists are long -- I don't want to load the whole list upon pageview. So I load the first ten for each.

The question

Now I can provide dynamic paging for each of the lists in one of two ways:

1. Get the data for the next 10 users as json. Write js to render this data, replacing the contents of the div.
2. Get a rendered "snippet" of html from another well defined URL on my server, say /users/bob/tags/footag/received?page=1. I fetch it asynchronously and just replace the contents of the relevant <div>.

So in one case I fetch data and render it via JS in the browser, the other I fetch rendered data and just plonk it wholesale into the document.

Is there any reason not to use #2? I can't imagine one but I suppose there might be security aspects I'm not considering, or performance, or something else. I'd much prefer to do #2 as it simplifies my life significantly.

Thanks!

Answer 1

I would personally use method #2. Why waste time with client-side parsing that could be easily, and better, done using a server-side language? Instead of creating an array and then converting it to json, it would be much better to just loop through the results and echo HTML.

Answer 2

well, apart from the slight overhead of the formatting being loaded from the server, which could make it slightly slower for a large amount of data, I can't see any drawbacks. And as javascript rendering would probably be slow too, I would go with #2.

Answer 3

I would benchmark it in a few browsers, but I suspect #1 (transmit as JSON) could actually prove faster. With that method, you can simply replace values for existing DOM nodes. E.g. (very simplified) change (directly using DOM manipulation):

<li>foo</li>
<li>bar</li>
<li>baz</li>

to:

<li>foo2</li>
<li>bar2</li>
<li>baz2</li>

when you get the JSON:

["foo2", "bar2", "baz2"]

This way, you're not creating new DOM nodes unnecessarily. Another advantage is a JSON API is more "appetizing" if you later decide to make it public in some form.

Answer 4

i'd go with #1 ... so you really get the data, not just some HTML ... it will simply be a concise JavaScript object structure and not some string, so you can evaluate the data at will, cache it, use it for searches, etc. ... the more work is done on the client side, and the cleverer it is, the better you app scales ... you have 1 server, or maybe 2-10, or i don't know, but you have 10-10000 more clients ...

Answer 5

I've got an app like this -- I use both methods.

I use your Method #1 to update fields that aren't contiguous (e.g. input fields all over the place), but I use your Method #2 to update tabular data, kind of like your lists.

I would stick to #2 for your case.

Answer 6

I say #1 for most instances. If you wanted to add a "next/prev" page button outside of the div being updated, then you can use JS to determin when to enable/disable them. Using #1 gives you much more flexibility and further decouples data from presentation.

The performance and "ease of development" is negligible in my opinion. Performance isn't very big anymore for smaller "chunks" of data (assuming your JS in in the realm of sanity) and "ease of development" isn't much of a factor considering that this is easier to maintain.