On 12/8/2011 9:27 AM, Bill Dueber wrote:
> To these I would add:
>
> * Reuse. The call you're making may be providing data that would be useful
> in other contexts as well. If you're generating application-specific html,
> that can't happen.

Well, if the other contexts are Javascript, and your HTML is nice 
semantically structured with good classes and ID's....  it actually ends 
up being just about as easy getting the data out of HTML with JQuery 
selectors as it would be with JSON.

This is kind of the direction of HTML5 microdata/schema.org --- 
realizing that properly structured semantic HTML can be pretty damn 
machine readable, so if you do that you can get human HTML and machine 
readability with only one representation, instead of having to maintain 
multiple representations. (In some of the scenarios we're talking about, 
there are potentially THREE representations to maintain -- server-side 
generated HTML, server-side generated JSON, AND js to turn the JSON into 
HTML).

But yeah, there are always lots of trade-offs. This particular question 
I think ends up depending on a lot on what choices you've made for the 
REST of your software stack. Each choice at each level has different 
trade-offs, but the most important thing is probably to reduce the 
'impedence' of making inconsistent choices in different places. That is 
-- if you're heavy into client-side JS app framework rendering of HTML 
already, then sure you've made your choice, stick to it.